path: root/docs/docsite/rst/locales/ja/LC_MESSAGES/dev_guide.po

# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2021 Red Hat, Inc.
# 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: 2022-10-05 09:34+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.8.1\n"

#: ../../rst/dev_guide/ansible_index.rst:5 ../../rst/dev_guide/core_index.rst:5
msgid "Developer Guide"
msgstr "開発者ガイド"

#: ../../rst/dev_guide/ansible_index.rst:9 ../../rst/dev_guide/core_index.rst:9
msgid "**Making Open Source More Inclusive**"
msgstr "**多様性を受け入れるオープンソースの強化**"

#: ../../rst/dev_guide/ansible_index.rst:11
#: ../../rst/dev_guide/core_index.rst:11
msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message <https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language>`_."
msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ <https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language>`_ を参照してください。"

#: ../../rst/dev_guide/ansible_index.rst:13
#: ../../rst/dev_guide/core_index.rst:13
msgid "Welcome to the Ansible Developer Guide!"
msgstr "Ansible 開発者ガイドにようこそ!"

#: ../../rst/dev_guide/ansible_index.rst:15
#: ../../rst/dev_guide/core_index.rst:15
msgid "**Who should use this guide?**"
msgstr "**本ガイドの対象者**"

#: ../../rst/dev_guide/ansible_index.rst:17
#: ../../rst/dev_guide/core_index.rst:17
msgid "If you want to extend Ansible by using a custom module or plugin locally, creating a module or plugin, adding functionality to an existing module, or expanding test coverage, this guide is for you. We've included detailed information for developers on how to test and document modules, as well as the prerequisites for getting your module or plugin accepted into the main Ansible repository."
msgstr "カスタムモジュールまたはプラグインのローカルでの使用、モジュールまたはプラグインの作成、既存のモジュールへの機能の追加、テスト範囲の拡張を行って Ansible を拡張する場合は、このガイドをご利用になれます。モジュールのテストおよびドキュメント化に関する方法についての開発者向けの詳細情報、および主な Ansible リポジトリーに受け入れられるモジュールまたはプラグインを取得するための前提条件が記載されています。"

#: ../../rst/dev_guide/ansible_index.rst:19
#: ../../rst/dev_guide/core_index.rst:19
msgid "Find the task that best describes what you want to do:"
msgstr "以下の中から、お客様のニーズに最も適したタスクを選んでください。"

#: ../../rst/dev_guide/ansible_index.rst:21
#: ../../rst/dev_guide/core_index.rst:21
msgid "I'm looking for a way to address a use case:"
msgstr "ユースケースに対応する方法を探している。"

#: ../../rst/dev_guide/ansible_index.rst:23
#: ../../rst/dev_guide/core_index.rst:23
msgid "I want to :ref:`add a custom plugin or module locally <developing_locally>`."
msgstr ":ref:`カスタムプラグインまたはモジュールをローカルに追加 <developing_locally>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:24
#: ../../rst/dev_guide/core_index.rst:24
msgid "I want to figure out if :ref:`developing a module is the right approach <module_dev_should_you>` for my use case."
msgstr "選択したユースケースでは、:ref:`モジュールの開発が適切なアプローチである <module_dev_should_you>` かどうかを確認したいです。"

#: ../../rst/dev_guide/ansible_index.rst:25
#: ../../rst/dev_guide/core_index.rst:25
msgid "I want to :ref:`develop a collection <developing_collections>`."
msgstr ":ref:`コレクションを開発 <developing_collections>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:26
#: ../../rst/dev_guide/core_index.rst:26
msgid "I want to :ref:`contribute to an Ansible-maintained collection <contributing_maintained_collections>`."
msgstr ":ref:`Ansible が管理するコレクションに貢献 <contributing_maintained_collections>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:27
#: ../../rst/dev_guide/core_index.rst:27
msgid "I want to :ref:`contribute to a community-maintained collection <hacking_collections>`."
msgstr ":ref:`コミュニティーが管理するコレクションに貢献 <hacking_collections>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:28
#: ../../rst/dev_guide/core_index.rst:28
msgid "I want to :ref:`migrate a role to a collection <migrating_roles>`."
msgstr ":ref:`ロールをコレクションに移行 <migrating_roles>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:30
#: ../../rst/dev_guide/core_index.rst:30
msgid "I've read the info above, and I'm sure I want to develop a module:"
msgstr "上記の情報を読んで、モジュールを開発したい。"

#: ../../rst/dev_guide/ansible_index.rst:32
#: ../../rst/dev_guide/core_index.rst:32
msgid "What do I need to know before I start coding?"
msgstr "コーディングを始める前に何を知っておくべきでしょうか。"

#: ../../rst/dev_guide/ansible_index.rst:33
#: ../../rst/dev_guide/core_index.rst:33
msgid "I want to :ref:`set up my Python development environment <environment_setup>`."
msgstr ":ref:`Python 開発環境をセットアップ <environment_setup>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:34
#: ../../rst/dev_guide/core_index.rst:34
msgid "I want to :ref:`get started writing a module <developing_modules_general>`."
msgstr ":ref:`モジュールの記述を開始 <developing_modules_general>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:40
#: ../../rst/dev_guide/core_index.rst:36
msgid "I want to write a specific kind of module:"
msgstr "特定のモジュールを作成したいです。"

#: ../../rst/dev_guide/ansible_index.rst:36
#: ../../rst/dev_guide/core_index.rst:36
msgid "a :ref:`network module <developing_modules_network>`"
msgstr ":ref:`ネットワークモジュール <developing_modules_network>`"

#: ../../rst/dev_guide/ansible_index.rst:37
#: ../../rst/dev_guide/core_index.rst:37
msgid "a :ref:`Windows module <developing_modules_general_windows>`."
msgstr ":ref:`Windows モジュール <developing_modules_general_windows>`"

#: ../../rst/dev_guide/ansible_index.rst:38
msgid "an :ref:`Amazon module <ansible_collections.amazon.aws.docsite.dev_guide_intro>`."
msgstr ":ref:`Amazon module <ansible_collections.amazon.aws.docsite.dev_guide_intro>`."

#: ../../rst/dev_guide/ansible_index.rst:39
msgid "an :ref:`OpenStack module <OpenStack_module_development>`."
msgstr ":ref:`OpenStack モジュール <OpenStack_module_development>`"

#: ../../rst/dev_guide/ansible_index.rst:40
msgid "an :ref:`oVirt/RHV module <oVirt_module_development>`."
msgstr ":ref:`oVirt/RHV モジュール <oVirt_module_development>`"

#: ../../rst/dev_guide/ansible_index.rst:41
msgid "a :ref:`VMware module <ansible_collections.community.vmware.docsite.vmware_ansible_devguide>`."
msgstr ":ref:`VMware module <ansible_collections.community.vmware.docsite.vmware_ansible_devguide>`"

#: ../../rst/dev_guide/ansible_index.rst:42
#: ../../rst/dev_guide/core_index.rst:38
msgid "I want to :ref:`write a series of related modules <developing_modules_in_groups>` that integrate Ansible with a new product (for example, a database, cloud provider, network platform, and so on)."
msgstr "Ansible を新規製品 (例: データベース、クラウドプロバイダー、ネットワークプラットフォーム) と統合する :ref:`一連の関連モジュールを記述 <developing_modules_in_groups>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:44
#: ../../rst/dev_guide/core_index.rst:40
msgid "I want to refine my code:"
msgstr "コードを改良したいです。"

#: ../../rst/dev_guide/ansible_index.rst:46
#: ../../rst/dev_guide/core_index.rst:42
msgid "I want to :ref:`debug my module code <debugging_modules>`."
msgstr ":ref:`モジュールコードをデバッグ <debugging_modules>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:47
#: ../../rst/dev_guide/core_index.rst:43
msgid "I want to :ref:`add tests <developing_testing>`."
msgstr ":ref:`テストを追加 <developing_testing>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:48
#: ../../rst/dev_guide/core_index.rst:44
msgid "I want to :ref:`document my module <module_documenting>`."
msgstr ":ref:`モジュールをドキュメント化 <module_documenting>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:49
#: ../../rst/dev_guide/core_index.rst:45
msgid "I want to :ref:`document my set of modules for a network platform <documenting_modules_network>`."
msgstr ":ref:`ネットワークプラットフォームのモジュールセットを文書化 <documenting_modules_network>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:50
#: ../../rst/dev_guide/core_index.rst:46
msgid "I want to follow :ref:`conventions and tips for clean, usable module code <developing_modules_best_practices>`."
msgstr ":ref:`クリーンで使いやすいモジュールコードのための規則とヒント <developing_modules_best_practices>` を適用したいです。"

#: ../../rst/dev_guide/ansible_index.rst:51
#: ../../rst/dev_guide/core_index.rst:47
msgid "I want to :ref:`make sure my code runs on Python 2 and Python 3 <developing_python_3>`."
msgstr ":ref:`作成したコードが Python 2 および Python 3 で実行する <developing_python_3>` ようにしたいです。"

#: ../../rst/dev_guide/ansible_index.rst:53
#: ../../rst/dev_guide/core_index.rst:49
msgid "I want to work on other development projects:"
msgstr "他の開発プロジェクトで作業したいです。"

#: ../../rst/dev_guide/ansible_index.rst:55
#: ../../rst/dev_guide/core_index.rst:51
msgid "I want to :ref:`write a plugin <developing_plugins>`."
msgstr ":ref:`プラグインを記述 <developing_plugins>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:56
#: ../../rst/dev_guide/core_index.rst:52
msgid "I want to :ref:`connect Ansible to a new source of inventory <developing_inventory>`."
msgstr ":ref:`Ansible を新しいインベントリーソースに接続 <developing_inventory>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:57
#: ../../rst/dev_guide/core_index.rst:53
msgid "I want to :ref:`deprecate an outdated module <deprecating_modules>`."
msgstr ":ref:`古いモジュールを非推奨 <deprecating_modules>` にしたいです。"

#: ../../rst/dev_guide/ansible_index.rst:59
#: ../../rst/dev_guide/core_index.rst:55
msgid "I want to contribute back to the Ansible project:"
msgstr "Ansible プロジェクトに貢献したいです。"

#: ../../rst/dev_guide/ansible_index.rst:61
#: ../../rst/dev_guide/core_index.rst:57
msgid "I want to :ref:`understand how to contribute to Ansible <ansible_community_guide>`."
msgstr ":ref:`Ansible への貢献方法を理解 <ansible_community_guide>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:62
#: ../../rst/dev_guide/core_index.rst:58
msgid "I want to :ref:`contribute my module or plugin <developing_modules_checklist>`."
msgstr ":ref:`モジュールまたはプラグインに貢献 <developing_modules_checklist>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:63
#: ../../rst/dev_guide/core_index.rst:59
msgid "I want to :ref:`understand the license agreement <contributor_license_agreement>` for contributions to Ansible."
msgstr "Ansible に参加するための :ref:`使用許諾契約を理解 <contributor_license_agreement>` したいです。"

#: ../../rst/dev_guide/ansible_index.rst:65
#: ../../rst/dev_guide/core_index.rst:61
msgid "If you prefer to read the entire guide, here's a list of the pages in order."
msgstr "本ガイドをすべて読む場合は、以下に示す順番でページを表示してください。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:5
msgid "Collection Galaxy metadata structure"
msgstr "コレクション Galaxy メタデータ構造"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:7
msgid "A key component of an Ansible collection is the ``galaxy.yml`` file placed in the root directory of a collection. This file contains the metadata of the collection that is used to generate a collection artifact."
msgstr "Ansible コレクションの主なコンポーネントは、コレクションのルートディレクトリーに置いてある ``galaxy.yml`` ファイルです。このファイルには、コレクションアーティファクトの生成に使用されるコレクションのメタデータが含まれます。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:11
msgid "Structure"
msgstr "構造"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:13
msgid "The ``galaxy.yml`` file must contain the following keys in valid YAML:"
msgstr "``galaxy.yml`` ファイルの有効な YAML に以下のキーが含まれている必要があります。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:22
msgid "Key"
msgstr "キー"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:23
msgid "Comment"
msgstr "コメント"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:27
msgid "namespace |br|"
msgstr "namespace |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:31
#: ../../rst/dev_guide/collections_galaxy_meta.rst:55
#: ../../rst/dev_guide/collections_galaxy_meta.rst:77
#: ../../rst/dev_guide/collections_galaxy_meta.rst:99
#: ../../rst/dev_guide/collections_galaxy_meta.rst:143
#: ../../rst/dev_guide/collections_galaxy_meta.rst:175
#: ../../rst/dev_guide/collections_galaxy_meta.rst:229
#: ../../rst/dev_guide/collections_galaxy_meta.rst:243
#: ../../rst/dev_guide/collections_galaxy_meta.rst:257
#: ../../rst/dev_guide/collections_galaxy_meta.rst:271
msgid "string |_|"
msgstr "文字列 |_|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:35
#: ../../rst/dev_guide/collections_galaxy_meta.rst:59
#: ../../rst/dev_guide/collections_galaxy_meta.rst:81
#: ../../rst/dev_guide/collections_galaxy_meta.rst:103
#: ../../rst/dev_guide/collections_galaxy_meta.rst:125
msgid "/ |_|"
msgstr "/ |_|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:39
#: ../../rst/dev_guide/collections_galaxy_meta.rst:63
#: ../../rst/dev_guide/collections_galaxy_meta.rst:85
#: ../../rst/dev_guide/collections_galaxy_meta.rst:107
#: ../../rst/dev_guide/collections_galaxy_meta.rst:129
#: ../../rst/dev_guide/developing_modules_documenting.rst
#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "required"
msgstr "必須"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:41
msgid "The namespace of the collection."
msgstr "コレクションの名前空間。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:43
msgid "This can be a company/brand/organization or product namespace under which all content lives."
msgstr "これには、企業/ブランド/組織、またはすべてのコンテンツが置かれる製品の名前空間を指定できます。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:45
msgid "May only contain alphanumeric lowercase characters and underscores. Namespaces cannot start with underscores or numbers and cannot contain consecutive underscores."
msgstr "英数字 (小文字) とアンダースコアのみを使用できます。名前空間はアンダースコアや数字で開始できず、連続したアンダースコアを含めることはできません。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:51
msgid "name |br|"
msgstr "name |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:65
msgid "The name of the collection."
msgstr "コレクションの名前。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:67
msgid "Has the same character restrictions as \\ :literal:`namespace`\\ ."
msgstr "\\ :literal:`namespace`\\ と同じ文字制限があります。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:73
msgid "version |br|"
msgstr "version |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:87
msgid "The version of the collection."
msgstr "コレクションのバージョン。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:89
msgid "Must be compatible with semantic versioning."
msgstr "セマンティックバージョニングと互換性がある必要があります。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:95
msgid "readme |br|"
msgstr "readme |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:109
msgid "The path to the Markdown (.md) readme file."
msgstr "マークダウン (.md) readme ファイルへのパス。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:111
#: ../../rst/dev_guide/collections_galaxy_meta.rst:181
msgid "This path is relative to the root of the collection."
msgstr "このパスは、コレクションのルートに相対します。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:117
msgid "authors |br|"
msgstr "authors |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:121
#: ../../rst/dev_guide/collections_galaxy_meta.rst:157
#: ../../rst/dev_guide/collections_galaxy_meta.rst:193
#: ../../rst/dev_guide/collections_galaxy_meta.rst:285
msgid "list |_|"
msgstr "リスト |_|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:131
msgid "A list of the collection's content authors."
msgstr "コレクションのコンテンツ作成者の一覧。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:133
msgid "Can be just the name or in the format 'Full Name <email> (url) @nicks:irc/im.site#channel'."
msgstr "名前または形式には、「氏名 <email> (url) @nicks:irc/im.site#channel」の形式しか指定できません。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:139
msgid "description |br|"
msgstr "description |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:147
msgid "A short summary description of the collection."
msgstr "コレクションの簡単な説明。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:153
msgid "license |br|"
msgstr "license |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:161
msgid "Either a single license or a list of licenses for content inside of a collection."
msgstr "コレクション内の 1 つのライセンスまたはコンテンツのライセンスの一覧。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:163
msgid "Ansible Galaxy currently only accepts \\ `SPDX <https://spdx.org/licenses/>`__\\  licenses"
msgstr "現在 Ansible Galaxy は \\ `SPDX <https://spdx.org/licenses/>`__\\ ライセンスのみ受け付けます。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:165
msgid "This key is mutually exclusive with \\ :literal:`license\\_file`\\ ."
msgstr "このキーは、\\ :literal:`license\\_file`\\ と相互に排他的です。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:171
msgid "license_file |br|"
msgstr "license_file |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:179
msgid "The path to the license file for the collection."
msgstr "コレクションのライセンスファイルへのパス。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:183
msgid "This key is mutually exclusive with \\ :literal:`license`\\ ."
msgstr "このキーは、\\ :literal:`license`\\ と相互に排他的です。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:189
msgid "tags |br|"
msgstr "tags |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:197
msgid "A list of tags you want to associate with the collection for indexing/searching."
msgstr "インデックス化/検索のコレクションに関連付けるタグの一覧。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:199
msgid "A tag name has the same character requirements as \\ :literal:`namespace`\\  and \\ :literal:`name`\\ ."
msgstr "タグ名には、\\ :literal:`namespace`\\ および \\ :literal:`name`\\ と同じ文字要件があります。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:205
msgid "dependencies |br|"
msgstr "dependencies |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:209
msgid "dictionary |_|"
msgstr "ディクショナリー |_|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:213
msgid "Collections that this collection requires to be installed for it to be usable."
msgstr "利用できるように、このコレクションをインストールする必要があるコレクション。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:215
msgid "The key of the dict is the collection label \\ :literal:`namespace.name`\\ ."
msgstr "ディクショナリーのキーはコレクションラベル \\ :literal:`namespace.name`\\ です。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:217
msgid "The value is a version range \\ `specifiers <https://python-semanticversion.readthedocs.io/en/latest/#requirement-specification>`__\\ ."
msgstr "この値は、\\ `specifiers <https://python-semanticversion.readthedocs.io/en/latest/#requirement-specification>`__\\ のバージョン範囲です。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:219
msgid "Multiple version range specifiers can be set and are separated by \\ :literal:`,`\\ ."
msgstr "複数のバージョン範囲指定子を設定でき、\\ :literal:`,`\\ で区切ることができます。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:225
msgid "repository |br|"
msgstr "repository |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:233
msgid "The URL of the originating SCM repository."
msgstr "元の SCM リポジトリーの URL。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:239
msgid "documentation |br|"
msgstr "documentation |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:247
msgid "The URL to any online docs."
msgstr "オンラインドキュメントへの URL。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:253
msgid "homepage |br|"
msgstr "homepage |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:261
msgid "The URL to the homepage of the collection/project."
msgstr "コレクション/プロジェクトのホームページへの URL。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:267
msgid "issues |br|"
msgstr "issues |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:275
msgid "The URL to the collection issue tracker."
msgstr "コレクションの問題トラッカーへの URL。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:281
msgid "build_ignore |br|"
msgstr "build_ignore |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:290
msgid "|br| version_added: 2.10"
msgstr "|br| version_added: 2.10"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:292
#: ../../rst/dev_guide/collections_galaxy_meta.rst:318
msgid "|_|"
msgstr "|_|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:293
msgid "A list of file glob-like patterns used to filter any files or directories that should not be included in the build artifact."
msgstr "ビルドアーティファクトに含まれないファイルやディレクトリーをフィルタリングするのに使用されるファイルグロブのようなパターンの一覧。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:295
msgid "A pattern is matched from the relative path of the file or directory of the collection directory."
msgstr "パターンは、コレクションディレクトリーのファイルまたはディレクトリーの相対パスから照合されます。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:297
msgid "This uses \\ :literal:`fnmatch`\\  to match the files or directories."
msgstr "ここでは、\\ :literal:`fnmatch`\\ を使用してファイルまたはディレクトリーを照合します。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:299
msgid "Some directories and files like \\ :literal:`galaxy.yml`\\ , \\ :literal:`\\*.pyc`\\ , \\ :literal:`\\*.retry`\\ , and \\ :literal:`.git`\\  are always filtered."
msgstr "\\ :literal:`galaxy.yml`\\、\\ :literal:`\\*.pyc`\\、\\ :literal:`\\*.retry`\\、\\ :literal:`.git`\\ など一部のディレクトリーやファイルは常にフィルタリングされます。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:301
msgid "Mutually exclusive with \\ :literal:`manifest`\\"
msgstr " \\ :literal:`manifest`\\ と併用できません。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:307
msgid "manifest |br|"
msgstr "manifest |br|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:311
msgid "sentinel |_|"
msgstr "sentinel |_|"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:316
msgid "|br| version_added: 2.14"
msgstr "|br| version_added: 2.14"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:319
msgid "A dict controlling use of manifest directives used in building the collection artifact."
msgstr "コレクションアーティファクトの構築に使用されるマニフェストディレクティブの使用を制御する辞書。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:321
msgid "The key \\ :literal:`directives`\\  is a list of MANIFEST.in style \\ `directives <https://packaging.python.org/en/latest/guides/using-manifest-in/#manifest-in-commands>`__\\"
msgstr "キー \\ :literal:`directives`\\  は MANIFEST.in style \\ `directives <https://packaging.python.org/en/latest/guides/using-manifest-in/#manifest-in-commands>`__\\ のリストです。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:323
msgid "The key \\ :literal:`omit\\_default\\_directives`\\  is a boolean that controls whether the default directives are used"
msgstr "キー \\ :literal:`omit\\_default\\_directives`\\  は、デフォルトのディレクティブを使用するかどうかを制御するブール値です。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:325
msgid "Mutually exclusive with \\ :literal:`build\\_ignore`\\"
msgstr "\\ :literal:`build\\_ignore`\\ と併用できません。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:330
msgid "Examples"
msgstr "例"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:355
msgid ":ref:`developing_collections`"
msgstr ":ref:`developing_collections`"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:356
msgid "Develop or modify a collection."
msgstr "コレクションを開発するか、または変更します。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:357
#: ../../rst/dev_guide/developing_api.rst:40
#: ../../rst/dev_guide/developing_inventory.rst:475
#: ../../rst/dev_guide/developing_plugins.rst:544
#: ../../rst/dev_guide/testing_units_modules.rst:571
msgid ":ref:`developing_modules_general`"
msgstr ":ref:`developing_modules_general`"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:358
#: ../../rst/dev_guide/developing_plugins.rst:545
msgid "Learn about how to write Ansible modules"
msgstr "Ansible モジュールの作成方法について"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:359
#: ../../rst/dev_guide/developing_collections.rst:40
#: ../../rst/dev_guide/developing_collections_changelogs.rst:75
#: ../../rst/dev_guide/developing_collections_contributing.rst:58
#: ../../rst/dev_guide/developing_collections_creating.rst:54
#: ../../rst/dev_guide/developing_collections_distributing.rst:397
#: ../../rst/dev_guide/developing_collections_migrating.rst:129
#: ../../rst/dev_guide/developing_collections_shared.rst:87
msgid ":ref:`collections`"
msgstr ":ref:`collections`"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:360
#: ../../rst/dev_guide/developing_collections_changelogs.rst:76
#: ../../rst/dev_guide/developing_collections_contributing.rst:59
#: ../../rst/dev_guide/developing_collections_creating.rst:55
#: ../../rst/dev_guide/developing_collections_distributing.rst:398
#: ../../rst/dev_guide/developing_collections_migrating.rst:130
#: ../../rst/dev_guide/developing_collections_shared.rst:88
msgid "Learn how to install and use collections."
msgstr "コレクションのインストール方法および使用方法はこちらを参照してください。"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:361
#: ../../rst/dev_guide/developing_collections.rst:46
#: ../../rst/dev_guide/developing_collections_changelogs.rst:79
#: ../../rst/dev_guide/developing_collections_contributing.rst:62
#: ../../rst/dev_guide/developing_collections_creating.rst:58
#: ../../rst/dev_guide/developing_collections_distributing.rst:401
#: ../../rst/dev_guide/developing_collections_migrating.rst:133
#: ../../rst/dev_guide/developing_collections_shared.rst:91
#: ../../rst/dev_guide/developing_collections_structure.rst:290
#: ../../rst/dev_guide/developing_collections_testing.rst:96
#: ../../rst/dev_guide/developing_core.rst:19
#: ../../rst/dev_guide/developing_modules.rst:48
#: ../../rst/dev_guide/developing_plugins.rst:546
msgid "`Mailing List <https://groups.google.com/group/ansible-devel>`_"
msgstr "`メーリングリスト <https://groups.google.com/group/ansible-devel>`_"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:362
#: ../../rst/dev_guide/developing_collections.rst:47
#: ../../rst/dev_guide/developing_collections_changelogs.rst:80
#: ../../rst/dev_guide/developing_collections_contributing.rst:63
#: ../../rst/dev_guide/developing_collections_creating.rst:59
#: ../../rst/dev_guide/developing_collections_distributing.rst:402
#: ../../rst/dev_guide/developing_collections_migrating.rst:134
#: ../../rst/dev_guide/developing_collections_shared.rst:92
#: ../../rst/dev_guide/developing_collections_structure.rst:291
#: ../../rst/dev_guide/developing_collections_testing.rst:97
#: ../../rst/dev_guide/developing_core.rst:20
#: ../../rst/dev_guide/developing_plugins.rst:547
msgid "The development mailing list"
msgstr "開発メーリングリスト"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:363
msgid "`irc.libera.chat <https://libera.chat/>`_"
msgstr "`irc.libera.chat <https://libera.chat/>`_"

#: ../../rst/dev_guide/collections_galaxy_meta.rst:364
msgid "#ansible IRC chat channel"
msgstr "IRC チャットチャンネル (#ansible)"

#: ../../rst/dev_guide/core_branches_and_tags.rst:5
msgid "``ansible-core`` project branches and tags"
msgstr "``ansible-core`` プロジェクトのブランチとタグ"

#: ../../rst/dev_guide/core_branches_and_tags.rst:8
msgid "``devel`` branch"
msgstr "``devel`` ブランチ"

#: ../../rst/dev_guide/core_branches_and_tags.rst:10
msgid "All new development on the next version of ``ansible-core`` occurs exclusively in the ``devel`` branch, and all bugfixes to prior releases must first be merged to devel before being backported to one or more stable branches for inclusion in servicing releases. Around the Beta 1 milestone, a new ``stable-X.Y`` branch is cut from ``devel``, which is then updated to host development of the ``X.Y+1`` release. External automated testing of Ansible content from ``devel`` is not generally recommended."
msgstr "次のバージョンの ``ansible-core`` における新しい開発はすべて、``devel`` ブランチでのみ行われ、以前のリリースに対するすべてのバグ修正はまず devel にマージしてから、サービスリリースに含めるために 1 つ以上の安定したブランチにバックポートされる必要があります。ベータ 1 マイルストーンでは、新しい ``stable-X.Y`` ブランチは ``devel`` からカットされ、その後 ``X.Y+1`` リリースのホスト開発に更新されます。``devel`` からの Ansible コンテンツの外部自動テストは、一般的には推奨されません。"

#: ../../rst/dev_guide/core_branches_and_tags.rst:17
msgid "``stable-X.Y`` branches"
msgstr "``stable-X.Y`` ブランチ"

#: ../../rst/dev_guide/core_branches_and_tags.rst:19
msgid "All ``ansible-core`` ``X.Y.Z`` releases are created from a corresponding ``stable-X.Y`` branch. A release's stable branch is typically cut from ``devel`` around ``X.Y.0 beta 1`` (when the release is feature complete). All further bugfixes (no enhancements!) must be made against ``devel`` and backported to applicable stable branches."
msgstr "``ansible-core`` ``X.Y.Z`` リリースはすべて、対応する ``stable-X.Y`` ブランチから作成されます。リリースの安定したブランチは通常、``X.Y.0 beta 1`` の周りの ``devel`` から取り除かれます (リリースの機能完了時に)。追加のバグ修正 (機能拡張なし) は、``devel`` に対して作成し、該当する安定したブランチにバックポートする必要があります。"

#: ../../rst/dev_guide/core_branches_and_tags.rst:24
msgid "``vX.Y.Z`` tags"
msgstr "``vX.Y.Z`` tags"

#: ../../rst/dev_guide/core_branches_and_tags.rst:26
msgid "Each ``ansible-core vX.Y.Z`` release is tagged from the release commit in the corresponding ``stable-X.Y`` branch, allowing access to the exact source used to create the release. As of ``ansible-core`` 2.13, the auto-generated GitHub tarball of the tag contents is considered the official canonical release artifact."
msgstr "各 ``ansible-core vX.Y.Z`` リリースは、対応する ``stable-X.Y`` ブランチのリリースコミットからタグ付けされ、リリースの作成に使用された正確なソースへのアクセスが可能になります。``ansible-core`` 2.13 の時点で、タグコンテンツの自動生成された GitHub tarball は公式の正規リリースアーティファクトとみなされます。"

#: ../../rst/dev_guide/core_branches_and_tags.rst:34
msgid "``milestone`` branch"
msgstr "``milestone`` branch"

#: ../../rst/dev_guide/core_branches_and_tags.rst:36
msgid "A ``milestone`` branch is a slow-moving stream of the ``devel`` branch, intended for external testing of ``ansible-core`` features under active development. As described in the :ref:`ansible_core_roadmaps` for a given release, development is typically split into three phases of decreasing duration, with larger and more invasive changes targeted to be merged to ``devel`` in earlier phases. The ``milestone`` branch is updated to the contents of ``devel`` at the end of each development phase. This allows testing of semi-stable unreleased features on a predictable schedule without the exposure to the potential instability of the daily commit \"fire hose\" from ``devel``. When a release reaches the Beta 1 milestone, the ``milestone`` branch will be updated to the first ``devel`` commit after the version number has been increased. Further testing of the same release should be done from the new ``stable-X.Y`` branch that was created. If a severe issue that significantly affects community testing or stability is discovered in the ``milestone`` branch, the branch contents may require unscheduled adjustment, but not in a way that prevents fast-forward updates (for example, ``milestone``-only commits will not be created or cherry-picked from ``devel``)."
msgstr "``milestone`` ブランチは、動きの遅い ``devel`` ブランチのストリームで、アクティブな開発における ``ansible-core`` 機能の外部テストを目的としています。指定されたリリースの :ref:`ansible_core_roadmaps` で説明されているように、開発は通常、期間が短い 3 つのフェーズに分割され、早期のフェーズで大きく侵襲的な変化を ``devel`` にマージすることを目標とします。``milestone`` ブランチは、各開発フェーズの終了時に ``devel`` の内容に更新されます。これにより、``devel`` からの毎日のコミットである「fire hose」にさらされることなく、予測可能なスケジュールで、半安定的な未リリースの機能をテストできます。リリースが Beta 1 マイルストーンに到達すると、``milestone`` ブランチはバージョン番号を増やしたあとで最初の ``devel`` コミットに更新されます。同じリリースをさらにテストする場合は、作成した新しい ``stable-X.Y`` ブランチから行う必要があります。コミュニティーのテストや安定性に大きく影響する重大な問題が ``milestone`` ブランチで検出された場合、ブランチの内容には予定外の調整が必要になることもありますが、Fast Forward Upgrade を妨げることはありません (たとえば、``milestone``のみのコミットは作成されたり、``devel`` から選択されることはありません)。"

#: ../../rst/dev_guide/core_branches_and_tags.rst:48
msgid "The following example is for illustrative purposes only. See the :ref:`ansible_core_roadmaps` for accurate dates. For example, the ``milestone`` branch in 2.13 ``ansible-core`` roadmap updated as follows:"
msgstr "以下は説明のための例です。正確な日付は、:ref:`ansible_core_roadmaps` を参照してください。たとえば、2.13 ``ansible-core`` ロードマップの ``milestone`` は以下のように更新されます。"

#: ../../rst/dev_guide/core_branches_and_tags.rst:50
msgid "27-Sep-2021: 2.13 Development Phase 1 begins; ``milestone`` contents are updated to 2.12.0b1 with version number set to ``2.13.0.dev0``. Automated content testing that includes version-specific ignore files (e.g., ``ignore-2.12.txt``) should copy them for the current version (e.g., ``ignore-2.13.txt``) before this point to ensure that automated sanity testing against the ``milestone`` branch will continue to pass."
msgstr "2021 年 9 月 27 日: 2.13 開発フェーズ 1 が始まり、``milestone`` の内容は 2.12.0b1 に更新され、バージョン番号は ``2.13.0.dev0`` に設定されました。バージョン固有の無視ファイルを含む自動コンテンツテスト (例:``ignore-2.12.txt``) は、この時点より前にそれを現在のバージョン用にコピーする必要があります (例:``ignore-2.13.txt``)。そうすることで、``milestone`` ブランチに対する自動健全性テストに引き続き通過します。"

#: ../../rst/dev_guide/core_branches_and_tags.rst:54
msgid "13-Dec-2021: 2.13 Development Phase 2 begins; ``milestone`` contents are updated to the final commit from Development Phase 1"
msgstr "2021 年 12 月 13 日: 2.13 開発フェーズ 2 が始まります。``milestone`` の内容は開発フェーズ 1 からの最終コミットに更新されます"

#: ../../rst/dev_guide/core_branches_and_tags.rst:55
msgid "14-Feb-2022: 2.13 Development Phase 3 begins; ``milestone`` contents are updated to the final commit from Development Phase 2"
msgstr "2022 年 2 月 14 日: 2.13 開発フェーズ 3 が始まります。``milestone`` の内容は開発フェーズ 2 からの最終コミットに更新されます"

#: ../../rst/dev_guide/core_branches_and_tags.rst:56
msgid "11-Apr-2022: ``stable-2.13`` branch created with results from Development Phase 3 and freeze. ``2.13.0b1`` is released from ``stable-2.13``. Automated content testing should continue 2.13 series testing against the new branch. The ``devel`` version number is updated to ``2.14.0.dev0``, and ``milestone`` is updated to that point."
msgstr "2022 年 4 月 11 日: 開発フェーズ 3 の結果で作成された ``stable-2.13`` ブランチとフリーズ。``2.13.0b1`` が ``stable-2.13`` からリリースされます。自動コンテンツテストは、新しいブランチに対して 2.13 シリーズのテストを継続する必要があります。``devel`` バージョン番号が ``2.14.0.dev0`` に更新され、その時点まで ``milestone`` が更新されます。"

#: ../../rst/dev_guide/debugging.rst:5
msgid "Debugging modules"
msgstr "モジュールのデバッグ"

#: ../../rst/dev_guide/debugging.rst:13
msgid "Detailed debugging steps"
msgstr "詳細なデバッグ手順"

#: ../../rst/dev_guide/debugging.rst:15
msgid "Ansible modules are put together as a zip file consisting of the module file and the various Python module boilerplate inside of a wrapper script. To see what is actually happening in the module, you need to extract the file from the wrapper. The wrapper script provides helper methods that let you do that."
msgstr "Ansible モジュールは、モジュールファイルとラッパースクリプト内のさまざまな Python モジュールの boilerplate で構成される zip ファイルとしてまとめて置かれます。モジュールで実際に何が発生しているかを確認するには、ラッパーからファイルを抽出する必要があります。ラッパースクリプトは、これを可能にするヘルパーメソッドを提供します。"

#: ../../rst/dev_guide/debugging.rst:17
msgid "The following steps use ``localhost`` as the target host, but you can use the same steps to debug against remote hosts as well. For a simpler approach to debugging without using the temporary files, see :ref:`simple debugging <simple_debugging>`."
msgstr "以下の手順では、ターゲットホストに ``localhost`` を使用していますが、同じ手順を使用してリモートホストに対してデバッグすることもできます。一時ファイルを使用せずにデバッグを行う簡単な方法は、「:ref:`簡単なデバッグ <simple_debugging>`」を参照してください。"

#: ../../rst/dev_guide/debugging.rst:20
msgid "Set :envvar:`ANSIBLE_KEEP_REMOTE_FILES` to ``1`` on the control host so Ansible will keep the remote module files instead of deleting them after the module finishes executing. Use the ``-vvv`` option to make Ansible more verbose. This will display the file name of the temporary module file."
msgstr "コントロールホストで :envvar:`ANSIBLE_KEEP_REMOTE_FILES` を ``1`` に設定します。これにより、Ansible はモジュール実行後も削除せずにリモートモジュールファイルを維持します。``-vvv`` オプションを使用すると、Ansible の詳細が表示されます。一時モジュールファイルのファイル名が表示されます。"

#: ../../rst/dev_guide/debugging.rst:40
msgid "Navigate to the temporary directory from the previous step. If the previous command was run against a remote host, connect to that host first before trying to navigate to the temporary directory."
msgstr "前の手順から一時ディレクトリーに移動します。前のコマンドがリモートホストに対して実行した場合は、最初にそのホストに接続します。一時ディレクトリーに移動する前に、そのホストに接続します。"

#: ../../rst/dev_guide/debugging.rst:47
msgid "Run the wrapper's ``explode`` command to turn the string into some Python files that you can work with."
msgstr "ラッパーの ``explode`` コマンドを実行して、文字列を使用可能な Python ファイルに変換します。"

#: ../../rst/dev_guide/debugging.rst:55
msgid "If you want to examine the wrapper file you can. It will show a small Python script with a large base64 encoded string. The string contains the module to execute."
msgstr "ラッパーファイルを調べたい場合は、小さい Python スクリプトに、大きな base64 でエンコードされた文字列が記載されます。文字列には、実行するモジュールが含まれます。"

#: ../../rst/dev_guide/debugging.rst:57
msgid "When you look into the temporary directory you'll see a structure like this:"
msgstr "一時ディレクトリーを確認すると、以下のような構造が表示されます。"

#: ../../rst/dev_guide/debugging.rst:80
msgid "``AnsiballZ_ping.py`` is the Python script with the module code stored in a base64 encoded string. It contains various helper functions for executing the module."
msgstr "``AnsiballZ_ping.py`` base64 でエンコードされた文字列に保存されたモジュールコードを含む Python スクリプトで、モジュールを実行するためのさまざまなヘルパー関数が含まれます。"

#: ../../rst/dev_guide/debugging.rst:82
msgid "``ping.py`` is the code for the module itself. You can modify this code to see what effect it would have on your module, or for debugging purposes."
msgstr "``ping.py`` は、モジュール自体のコードです。このコードを変更して、モジュールまたはデバッグの目的を確認することができます。"

#: ../../rst/dev_guide/debugging.rst:84
msgid "The ``args`` file contains a JSON string. The string is a dictionary containing the module arguments and other variables that Ansible passes into the module to change its behavior. Modify this file to change the parameters passed to the module."
msgstr "``args`` ファイルには JSON 文字列が含まれています。この文字列は、モジュール引数および、Ansible がモジュールに渡すその他の変数を含むディクショナリーで、動作を変更します。このファイルを変更して、モジュールに渡されるパラメーターを変更します。"

#: ../../rst/dev_guide/debugging.rst:86
msgid "The ``ansible`` directory contains the module code in ``modules`` as well as code from :mod:`ansible.module_utils` that is used by the module. Ansible includes files for any :mod:`ansible.module_utils` imports in the module but not any files from any other module. If your module uses :mod:`ansible.module_utils.url` Ansible will include it for you. But if your module includes `requests <https://requests.readthedocs.io/en/latest/api/>`_, then you'll have to make sure that the Python `requests library <https://pypi.org/project/requests/>`_ is installed on the system before running the module."
msgstr "``ansible`` ディレクトリーには、``modules`` のモジュールコードと、モジュールに使用される :mod:`ansible.module_utils` のコードが含まれています。Ansible には、モジュール内の :mod:`ansible.module_utils` インポートのファイルが含まれますが、他のモジュールからのファイルは含まれません。モジュールで :mod:`ansible.module_utils.url` が使用される場合は、Ansible にそれが含まれます。ただし、モジュールに `requests <https://requests.readthedocs.io/en/latest/api/>`_ が含まれる場合は、モジュールを実行する前に Python `requests library <https://pypi.org/project/requests/>`_ がシステムにインストールされていることを確認する必要があります。"

#: ../../rst/dev_guide/debugging.rst:88
msgid "You can modify files in this directory if you suspect that the module is having a problem in some of this boilerplate code rather than in the module code you have written."
msgstr "作成したモジュールコードではなく、モジュールのこの boilerplate コードの一部に問題があると思われる場合は、このディレクトリーのファイルを変更できます。"

#: ../../rst/dev_guide/debugging.rst:90
msgid "Once you edit the code or arguments in the exploded tree, use the ``execute`` subcommand to run it:"
msgstr "展開されたツリーのコードまたは引数を編集したら、``execute`` サブコマンドを使用してこれを実行します。"

#: ../../rst/dev_guide/debugging.rst:97
msgid "This subcommand inserts the absolute path to ``debug_dir`` as the first item in ``sys.path`` and invokes the script using the arguments in the ``args`` file. You can continue to run the module like this until you understand the problem. Then you can copy the changes back into your real module file and test that the real module works via ``ansible`` or ``ansible-playbook``."
msgstr "このサブコマンドは、``sys.path`` の最初の項目として ``debug_dir`` に絶対パスを挿入し、``args`` ファイルの引数を使用してスクリプトを呼び出します。問題を理解するまで、このモジュールの実行を継続できます。変更を実際のモジュールファイルにコピーし、実際のモジュールが ``ansible`` または ``ansible-playbook`` で動作することをテストすることができます。"

#: ../../rst/dev_guide/debugging.rst:103
msgid "Simple debugging"
msgstr "簡単なデバッグ"

#: ../../rst/dev_guide/debugging.rst:105
msgid "The easiest way to run a debugger in a module, either local or remote, is to use `epdb <https://pypi.org/project/epdb/>`_. Add ``import epdb; epdb.serve()`` in the module code on the control node at the desired break point. To connect to the debugger, run ``epdb.connect()``. See the `epdb documentation <https://pypi.org/project/epdb/>`_ for how to specify the ``host`` and ``port``. If connecting to a remote node, make sure to use a port that is allowed by any firewall between the control node and the remote node."
msgstr "モジュール (ローカルまたはリモートのいずれか) でデバッガーを実行する最も簡単な方法は、`epdb <https://pypi.org/project/epdb/>`_ を使用します。任意のブレークポイントで、コントロールノードのモジュールコードに ``import epdb; epdb.serve()`` を追加します。デバッガーに接続するには、``epdb.connect()`` を実行します。``host`` および ``port`` を指定する方法は、`epdb ドキュメント <https://pypi.org/project/epdb/>`_ を参照してください。リモートノードに接続する場合は、コントロールノードとリモートノードとの間のファイアウォールが許可されているポートを使用するようにしてください。"

#: ../../rst/dev_guide/debugging.rst:107
msgid "This technique should work with any remote debugger, but we do not guarantee any particular remote debugging tool will work."
msgstr "この手法はリモートデバッガーと動作しますが、特定のリモートデバッグツールが機能する保証はありません。"

#: ../../rst/dev_guide/debugging.rst:109
msgid "The `q <https://pypi.org/project/q/>`_ library is another very useful debugging tool."
msgstr "`q <https://pypi.org/project/q/>`_ ライブラリーは、もう 1 つの便利なデバッグツールです。"

#: ../../rst/dev_guide/debugging.rst:111
msgid "Since ``print()`` statements do not work inside modules, raising an exception is a good approach if you just want to see some specific data. Put ``raise Exception(some_value)`` somewhere in the module and run it normally. Ansible will handle this exception, pass the message back to the control node, and display it."
msgstr "``print()`` ステートメントはモジュール内では機能しないため、特定のデータを確認する場合は例外を発生させます。モジュール内のどこかに ``raise Exception(some_value)`` を置き、通常どおり実行します。Ansible はこの例外を処理し、メッセージをコントロールノードに渡し、表示します。"

#: ../../rst/dev_guide/developing_api.rst:5
msgid "Python API"
msgstr "Python API"

#: ../../rst/dev_guide/developing_api.rst:7
#: ../../rst/dev_guide/developing_inventory.rst:17
#: ../../rst/dev_guide/developing_modules_best_practices.rst:9
#: ../../rst/dev_guide/testing_compile.rst:9
#: ../../rst/dev_guide/testing_httptester.rst:7
#: ../../rst/dev_guide/testing_integration.rst:9
#: ../../rst/dev_guide/testing_integration_legacy.rst:9
#: ../../rst/dev_guide/testing_pep8.rst:9
#: ../../rst/dev_guide/testing_sanity.rst:9
#: ../../rst/dev_guide/testing_units.rst:14
#: ../../rst/dev_guide/testing_units_modules.rst:11
#: ../../rst/dev_guide/testing_validate-modules.rst:9
msgid "Topics"
msgstr "トピック"

#: ../../rst/dev_guide/developing_api.rst:9
msgid "This API is intended for internal Ansible use. Ansible may make changes to this API at any time that could break backward compatibility with older versions of the API. Because of this, external use is not supported by Ansible. If you want to use Python API only for executing playbooks or modules, consider `ansible-runner <https://ansible-runner.readthedocs.io/en/latest/>`_ first."
msgstr "この API は、内部 Ansible の使用を目的としています。Ansible は、古いバージョンの API との後方互換性を妨げる可能性がある時点でこの API に変更を加えることができるため、Ansible では外部の使用はサポートされません。Playbook またはモジュールの実行のみに Python API を使用する場合は、まず `ansible-runner <https://ansible-runner.readthedocs.io/en/latest/>`_ を考慮してください。"

#: ../../rst/dev_guide/developing_api.rst:11
msgid "There are several ways to use Ansible from an API perspective.   You can use the Ansible Python API to control nodes, you can extend Ansible to respond to various Python events, you can write plugins, and you can plug in inventory data from external data sources.  This document gives a basic overview and examples of the Ansible execution and playbook API."
msgstr "API パースペクティブから Ansible を使用する方法は複数あります。Ansible Python API を使用してノードを制御し、Ansible を拡張してさまざまな Python イベントに応答でき、プラグインを作成したり、外部データソースからのインベントリーデータへのプラグインを行うことができます。本書では、Ansible の実行および Playbook API の基本的な概要と例を紹介します。"

#: ../../rst/dev_guide/developing_api.rst:16
msgid "If you would like to use Ansible programmatically from a language other than Python, trigger events asynchronously, or have access control and logging demands, please see the `AWX project <https://github.com/ansible/awx/>`_."
msgstr "Python 以外の言語で Ansible を使用して、イベントを非同期的にトリガーするか、アクセス制御およびログ要求をする場合は、「`AWX プロジェクト <https://github.com/ansible/awx/>`_」を参照してください。"

#: ../../rst/dev_guide/developing_api.rst:19
msgid "Because Ansible relies on forking processes, this API is not thread safe."
msgstr "Ansible はプロセスのフォークに依存しているため、この API はスレッドセーフではありません。"

#: ../../rst/dev_guide/developing_api.rst:24
msgid "Python API example"
msgstr "Python API の例"

#: ../../rst/dev_guide/developing_api.rst:26
msgid "This example is a simple demonstration that shows how to minimally run a couple of tasks:"
msgstr "この例は、いくつかのタスクを最小限に実行する方法を示す簡単なデモです。"

#: ../../rst/dev_guide/developing_api.rst:31
msgid "Ansible emits warnings and errors via the display object, which prints directly to stdout, stderr and the Ansible log."
msgstr "Ansible は、表示オブジェクトを介して警告とエラーを出力します。標準出力 (stdout)、標準エラー (stderr)、Ansible ログに直接出力します。"

#: ../../rst/dev_guide/developing_api.rst:33
msgid "The source code for the ``ansible`` command line tools (``lib/ansible/cli/``) is `available on GitHub <https://github.com/ansible/ansible/tree/devel/lib/ansible/cli>`_."
msgstr "``ansible`` コマンドラインツールのソースコード (``lib/ansible/cli/``) は `GitHub で利用 <https://github.com/ansible/ansible/tree/devel/lib/ansible/cli>`_ できます。"

#: ../../rst/dev_guide/developing_api.rst:38
#: ../../rst/dev_guide/developing_plugins.rst:542
msgid ":ref:`developing_inventory`"
msgstr ":ref:`developing_inventory`"

#: ../../rst/dev_guide/developing_api.rst:39
msgid "Developing dynamic inventory integrations"
msgstr "動的インベントリー統合の開発"

#: ../../rst/dev_guide/developing_api.rst:41
msgid "Getting started on developing a module"
msgstr "モジュール開発を始める"

#: ../../rst/dev_guide/developing_api.rst:42
#: ../../rst/dev_guide/developing_core.rst:17
#: ../../rst/dev_guide/developing_inventory.rst:477
msgid ":ref:`developing_plugins`"
msgstr ":ref:`developing_plugins`"

#: ../../rst/dev_guide/developing_api.rst:43
#: ../../rst/dev_guide/developing_inventory.rst:478
msgid "How to develop plugins"
msgstr "プラグインの開発方法"

#: ../../rst/dev_guide/developing_api.rst:44
#: ../../rst/dev_guide/developing_inventory.rst:481
#: ../../rst/dev_guide/testing_units_modules.rst:579
msgid "`Development Mailing List <https://groups.google.com/group/ansible-devel>`_"
msgstr "`Development Mailing List <https://groups.google.com/group/ansible-devel>`_"

#: ../../rst/dev_guide/developing_api.rst:45
#: ../../rst/dev_guide/developing_inventory.rst:482
#: ../../rst/dev_guide/testing_units_modules.rst:580
msgid "Mailing list for development topics"
msgstr "開発トピックのメーリングリスト"

#: ../../rst/dev_guide/developing_api.rst:46
#: ../../rst/dev_guide/developing_collections.rst:48
#: ../../rst/dev_guide/developing_collections_changelogs.rst:81
#: ../../rst/dev_guide/developing_collections_contributing.rst:64
#: ../../rst/dev_guide/developing_collections_creating.rst:60
#: ../../rst/dev_guide/developing_collections_distributing.rst:403
#: ../../rst/dev_guide/developing_collections_migrating.rst:135
#: ../../rst/dev_guide/developing_collections_shared.rst:93
#: ../../rst/dev_guide/developing_collections_structure.rst:292
#: ../../rst/dev_guide/developing_collections_testing.rst:98
#: ../../rst/dev_guide/developing_inventory.rst:483
#: ../../rst/dev_guide/developing_modules.rst:50
#: ../../rst/dev_guide/developing_plugins.rst:548
msgid ":ref:`communication_irc`"
msgstr ":ref:`communication_irc`"

#: ../../rst/dev_guide/developing_api.rst:47
#: ../../rst/dev_guide/developing_collections.rst:49
#: ../../rst/dev_guide/developing_collections_changelogs.rst:82
#: ../../rst/dev_guide/developing_collections_contributing.rst:65
#: ../../rst/dev_guide/developing_collections_creating.rst:61
#: ../../rst/dev_guide/developing_collections_distributing.rst:404
#: ../../rst/dev_guide/developing_collections_migrating.rst:136
#: ../../rst/dev_guide/developing_collections_shared.rst:94
#: ../../rst/dev_guide/developing_collections_structure.rst:293
#: ../../rst/dev_guide/developing_collections_testing.rst:99
#: ../../rst/dev_guide/developing_inventory.rst:484
#: ../../rst/dev_guide/developing_modules.rst:51
#: ../../rst/dev_guide/developing_plugins.rst:549
msgid "How to join Ansible chat channels"
msgstr "Ansible チャットチャンネルへの参加方法"

#: ../../rst/dev_guide/developing_collections.rst:11
msgid "Developing new collections"
msgstr "新規コレクションの開発"

#: ../../rst/dev_guide/developing_collections.rst:21
msgid "Working with existing collections"
msgstr "既存コレクションの使用"

#: ../../rst/dev_guide/developing_collections.rst:29
msgid "Collections references"
msgstr "コレクションの参照"

#: ../../rst/dev_guide/developing_collections.rst:5
msgid "Developing collections"
msgstr "コレクションの開発"

#: ../../rst/dev_guide/developing_collections.rst:7
msgid "Collections are a distribution format for Ansible content. You can package and distribute playbooks, roles, modules, and plugins using collections. A typical collection addresses a set of related use cases. For example, the ``cisco.ios`` collection automates management of Cisco IOS devices."
msgstr "コレクションは、Ansible コンテンツのディストリビューション形式です。コレクションを使用して Playbook、ロール、モジュール、およびプラグインをパッケージ化および分散できます。一般的なコレクションでは、関連する一連のユースケースに対応します。たとえば、``cisco.ios`` コレクションは Cisco IOS デバイスの管理を自動化します。"

#: ../../rst/dev_guide/developing_collections.rst:9
msgid "You can create a collection and publish it to `Ansible Galaxy <https://galaxy.ansible.com>`_ or to a private Automation Hub instance. You can publish certified collections to the Red Hat Automation Hub, part of the Red Hat Ansible Automation Platform."
msgstr "コレクションを作成して、`Ansible Galaxy <https://galaxy.ansible.com>`_ またはプライベート Automation Hub インスタンスに公開できます。Red Hat Ansible Automation Platform の一部である認定コレクションを Red Hat Automation Hub に公開できます。"

#: ../../rst/dev_guide/developing_collections.rst:36
msgid "For instructions on developing modules, see :ref:`developing_modules_general`."
msgstr "モジュール開発の手順は、「:ref:`developing_modules_general`」を参照してください。"

#: ../../rst/dev_guide/developing_collections.rst:41
msgid "Learn how to install and use collections in playbooks and roles"
msgstr "Playbook およびロールでコレクションをインストールして使用する方法を説明します。"

#: ../../rst/dev_guide/developing_collections.rst:42
#: ../../rst/dev_guide/developing_collections_changelogs.rst:77
#: ../../rst/dev_guide/developing_collections_contributing.rst:60
#: ../../rst/dev_guide/developing_collections_migrating.rst:131
#: ../../rst/dev_guide/developing_collections_shared.rst:89
#: ../../rst/dev_guide/developing_collections_structure.rst:288
#: ../../rst/dev_guide/developing_collections_testing.rst:94
msgid ":ref:`contributing_maintained_collections`"
msgstr ":ref:`contributing_maintained_collections`"

#: ../../rst/dev_guide/developing_collections.rst:43
#: ../../rst/dev_guide/developing_collections_changelogs.rst:78
#: ../../rst/dev_guide/developing_collections_contributing.rst:61
#: ../../rst/dev_guide/developing_collections_migrating.rst:132
#: ../../rst/dev_guide/developing_collections_shared.rst:90
#: ../../rst/dev_guide/developing_collections_structure.rst:289
#: ../../rst/dev_guide/developing_collections_testing.rst:95
msgid "Guidelines for contributing to selected collections"
msgstr "選択したコレクションに貢献するガイドライン"

#: ../../rst/dev_guide/developing_collections.rst:44
msgid "`Ansible Collections Overview and FAQ <https://github.com/ansible-collections/overview/blob/main/README.rst>`_"
msgstr "`Ansible Collections Overview and FAQ <https://github.com/ansible-collections/overview/blob/main/README.rst>`_"

#: ../../rst/dev_guide/developing_collections.rst:45
msgid "Current development status of community collections and FAQ"
msgstr "コミュニティーコレクションおよび FAQ の現在の開発ステータス"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:5
msgid "Generating changelogs and porting guide entries in a collection"
msgstr "コレクションで変更ログおよび移植ガイドエントリーの生成"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:7
msgid "You can create and share changelog and porting guide entries for your collection. If your collection is part of the Ansible Community package, we recommend that you use the `antsibull-changelog <https://github.com/ansible-community/antsibull-changelog>`_ tool to generate Ansible-compatible changelogs. The Ansible changelog uses the output of this tool to collate all the collections included in an Ansible release into one combined changelog for the release."
msgstr "コレクションの変更ログおよび移植ガイドを作成して共有できます。コレクションが Ansible Community パッケージの一部である場合は、`antsibull-changelog <https://github.com/ansible-community/antsibull-changelog>`_ ツールを使用して Ansible 互換の変更ログを生成することが推奨されます。Ansible の変更ログでは、このツールを使用して、このツールの出力を使用して、Ansible リリースに含まれるすべてのコレクションを、このリリースに対して 1 つの変更ログにまとめることが推奨されます。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:11
msgid "Ansible here refers to the Ansible 2.10 or later release that includes a curated set of collections."
msgstr "Ansible は、指定したコレクションセットを含む Ansible 2.10 以降のリリースを参照します。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:18
msgid "Understanding antsibull-changelog"
msgstr "antsibull-changelog について"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:20
msgid "The ``antsibull-changelog`` tool allows you to create and update changelogs for Ansible collections that are compatible with the combined Ansible changelogs. This is an update to the changelog generator used in prior Ansible releases. The tool adds three new changelog fragment categories: ``breaking_changes``, ``security_fixes`` and ``trivial``. The tool also generates the ``changelog.yaml`` file that Ansible uses to create the combined ``CHANGELOG.rst`` file and Porting Guide for the release."
msgstr "``antsibull-changelog`` ツールを使用すると、組み合わせた Ansible の変更ログと互換性のある Ansible コレクションに対して変更ログを作成し、更新できます。これは、Ansible リリース以前で使用される変更ログジェネレーターに対する更新です。このツールは、``breaking_changes``、``security_fixes``、および ``trivial`` の 3 つの新しい変更ログフラグメントカテゴリーを追加します。このツールは、Ansible がリリースを組み合わせた ``CHANGELOG.rst`` ファイルと移植ガイドを作成するために使用する ``changelog.yaml`` ファイルも生成します。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:22
msgid "See :ref:`changelogs_how_to` and the `antsibull-changelog documentation <https://github.com/ansible-community/antsibull-changelog/tree/main/docs>`_ for complete details."
msgstr "詳細は、「:ref:`changelogs_how_to`」および `antsibull-changelog ドキュメント <https://github.com/ansible-community/antsibull-changelog/tree/main/docs>`_ を参照してください。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:26
msgid "The collection maintainers set the changelog policy for their collections. See the individual collection contributing guidelines for complete details."
msgstr "コレクションのメンテナーは、コレクションに変更ログポリシーを設定します。詳細は、個々のコレクションの貢献ガイドラインを参照してください。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:29
msgid "Generating changelogs"
msgstr "変更ログの生成"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:31
msgid "To initialize changelog generation:"
msgstr "変更ログの生成を初期化するには、以下を実行します。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:33
msgid "Install ``antsibull-changelog``: :code:`pip install antsibull-changelog`."
msgstr "``antsibull-changelog`` をインストールします (:code:`pip install antsibull-changelog`)。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:34
msgid "Initialize changelogs for your repository: :code:`antsibull-changelog init <path/to/your/collection>`."
msgstr "リポジトリーの変更ログを初期化します (:code:`antsibull-changelog init <path/to/your/collection>`)。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:35
msgid "Optionally, edit the ``changelogs/config.yaml`` file to customize the location of the generated changelog ``.rst`` file or other options. See `Bootstrapping changelogs for collections <https://github.com/ansible-community/antsibull-changelog/blob/main/docs/changelogs.rst#bootstrapping-changelogs-for-collections>`_ for details."
msgstr "必要に応じて、``changelogs/config.yaml`` ファイルを編集して、生成された変更ログの ``.rst`` ファイルまたはその他のオプションをカスタマイズします。詳細は、「`コレクションの変更ログのブートストラップ <https://github.com/ansible-community/antsibull-changelog/blob/main/docs/changelogs.rst#bootstrapping-changelogs-for-collections>`_」を参照してください。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:37
msgid "To generate changelogs from the changelog fragments you created:"
msgstr "作成した変更ログフラグメントから変更ログを生成するには、以下を実行します。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:39
msgid "Optionally, validate your changelog fragments: :code:`antsibull-changelog lint`."
msgstr "必要に応じて、変更ログフラグメントを検証します (:code:`antsibull-changelog lint`) 。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:40
msgid "Generate the changelog for your release: :code:`antsibull-changelog release [--version version_number]`."
msgstr "リリースの変更ログ (:code:`antsibull-changelog release [--version version_number]`) を生成します。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:44
msgid "Add the  ``--reload-plugins`` option if you ran the ``antsibull-changelog release`` command previously and the version of the collection has not changed. ``antsibull-changelog`` caches the information on all plugins and does not update its cache until the collection version changes."
msgstr "以前に ``antsibull-changelog release`` コマンドを実行し、コレクションのバージョンが変更されていない場合は、``--reload-plugins`` オプションを追加します。``antsibull-changelog`` はすべてのプラグインに関する情報をキャッシュし、コレクションバージョンが変更されるまでキャッシュを更新しません。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:47
msgid "Porting Guide entries from changelog fragments"
msgstr "変更ログフラグメントの移植ガイドのエントリー"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:49
msgid "The Ansible changelog generator automatically adds several changelog fragment categories to the Ansible Porting Guide:"
msgstr "Ansible 変更ログジェネレーターは、複数の変更ログフラグメントカテゴリーを Ansible 移植ガイドに自動的に追加します。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:51
msgid "``major_changes``"
msgstr "``major_changes``"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:52
msgid "``breaking_changes``"
msgstr "``breaking_changes``"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:53
msgid "``deprecated_features``"
msgstr "``deprecated_features``"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:54
msgid "``removed_features``"
msgstr "``removed_features``"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:57
msgid "Including collection changelogs into Ansible"
msgstr "Ansible へのコレクション changelog の追加"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:59
msgid "If your collection is part of Ansible, use one of the following three options  to include your changelog into the Ansible release changelog:"
msgstr "コレクションが Ansible の一部である場合は、以下の 3 つのオプションのいずれかを使用して、作成した changelog を、Ansible リリースの changelog に追加します。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:61
msgid "Use the ``antsibull-changelog`` tool."
msgstr "``antsibull-changelog`` ツールの使用"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:63
msgid "If are not using this tool, include the properly formatted ``changelog.yaml`` file  into your collection. See the `changelog.yaml format <https://github.com/ansible-community/antsibull-changelog/blob/main/docs/changelog.yaml-format.md>`_ for details."
msgstr "このツールを使用していない場合は、適切に形式化された ``changelog.yaml`` ファイルをコレクションに追加します。詳細は、「`changelog.yaml 形式 <https://github.com/ansible-community/antsibull-changelog/blob/main/docs/changelog.yaml-format.md>`_」を参照してください。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:65
msgid "Add a link to own changelogs or release notes in any format by opening an issue at https://github.com/ansible-community/ansible-build-data/ with the HTML link to that information."
msgstr "この情報への HTML リンクで問題を https://github.com/ansible-community/ansible-build-data/ で開いて、任意の形式で独自の変更ログまたはリリースノートへのリンクを追加します。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:69
msgid "For the first two options, Ansible pulls the changelog details from Galaxy so your changelogs must be included in the collection version on Galaxy that is included in the upcoming Ansible release."
msgstr "最初の 2 つのオプションの場合、Ansible は変更ログの詳細を Galaxy からプルし、変更ログを今後の Ansible リリースに含まれる Galaxy のコレクションバージョンに追加する必要があります。"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:73
msgid ":ref:`collection_changelogs`"
msgstr ":ref:`collections`"

#: ../../rst/dev_guide/developing_collections_changelogs.rst:74
msgid "Learn how to create good changelog fragments."
msgstr "適切な Changelog フラグメントの作成方法はこちらを参照してください。"

#: ../../rst/dev_guide/developing_collections_contributing.rst:5
msgid "Contributing to collections"
msgstr "コレクションへの貢献"

#: ../../rst/dev_guide/developing_collections_contributing.rst:7
msgid "If you want to add functionality to an existing collection, modify a collection you are using to fix a bug, or change the behavior of a module in a collection, clone the git repository for that collection and make changes on a branch. You can combine changes to a collection with a local checkout of Ansible (``source hacking/env-setup``). You should first check the collection repository to see if it has specific contribution guidelines. These are typically listed in the README.md or CONTRIBUTING.md files within the repository."
msgstr "既存のコレクションに機能を追加するには、バグを修正するために使用するコレクションを変更したり、コレクションのモジュールの動作を変更して、そのコレクションの git リポジトリーのクローンを作成し、ブランチに変更を加えます。コレクションへの変更を、Ansible (``source hacking/env-setup``) のローカルチェックアウトと組み合わせることができます。まず、コレクションリポジトリーを確認して、特定の貢献ガイドラインが含まれているかどうかを確認します。通常、それらはリポジトリーの README.md ファイルまたは CONTRIBUTING.md ファイルに一覧表示されます。"

#: ../../rst/dev_guide/developing_collections_contributing.rst:11
msgid "Contributing to a collection: community.general"
msgstr "コレクションへの貢献: community.general"

#: ../../rst/dev_guide/developing_collections_contributing.rst:13
msgid "These instructions apply to collections hosted in the `ansible_collections GitHub organization <https://github.com/ansible-collections>`_. For other collections, especially for collections not hosted on GitHub, check the ``README.md`` of the collection for information on contributing to it."
msgstr "これらの手順は、`ansible_collections GitHub organization <https://github.com/ansible-collections>`_ にホストされるコレクションに適用されます。特に GitHub でホストされていないコレクションについては、これに貢献する情報について、コレクションの ``README.md`` を確認してください。"

#: ../../rst/dev_guide/developing_collections_contributing.rst:15
msgid "This example uses the `community.general collection <https://github.com/ansible-collections/community.general/>`_. To contribute to other collections in the same GitHub org, replace the folder names ``community`` and ``general`` with the namespace and collection name of a different collection."
msgstr "この例では、`community.general コレクション <https://github.com/ansible-collections/community.general/>`_ を使用しています。同じ GitHub Org の他のコレクションに貢献するために、フォルダー名 ``community`` および ``general`` を、別のコレクションの名前空間およびコレクション名に置き換えます。"

#: ../../rst/dev_guide/developing_collections_contributing.rst:18
#: ../../rst/dev_guide/testing_integration.rst:59
msgid "Prerequisites"
msgstr "要件"

#: ../../rst/dev_guide/developing_collections_contributing.rst:20
msgid "Include ``~/dev/ansible/collections/`` in :ref:`COLLECTIONS_PATHS`"
msgstr ":ref:`COLLECTIONS_PATHS` に ``~/dev/ansible/collections/`` を含めます"

#: ../../rst/dev_guide/developing_collections_contributing.rst:21
msgid "If that path mentions multiple directories, make sure that no other directory earlier in the search path contains a copy of ``community.general``."
msgstr "そのパスで複数のディレクトリーに言及されている場合は、検索パスの前のその他のディレクトリーに ``community.general`` のコピーが含まれないようにします。"

#: ../../rst/dev_guide/developing_collections_contributing.rst:24
msgid "Creating a PR"
msgstr "PR の作成"

#: ../../rst/dev_guide/developing_collections_contributing.rst:28
msgid "Create the directory ``~/dev/ansible/collections/ansible_collections/community``:"
msgstr "``~/dev/ansible/collections/ansible_collections/community`` ディレクトリーを作成します。"

#: ../../rst/dev_guide/developing_collections_contributing.rst:34
msgid "Clone `the community.general Git repository <https://github.com/ansible-collections/community.general/>`_ or a fork of it into the directory ``general``:"
msgstr "`community.general Git レポジトリー <https://github.com/ansible-collections/community.general/>`_ のクローンを作成するか、それを ``general`` ディレクトリーにフォークします。"

#: ../../rst/dev_guide/developing_collections_contributing.rst:41
msgid "If you clone from a fork, add the original repository as a remote ``upstream``:"
msgstr "フォークのクローンを作成したら、元のリポジトリーをリモートの ``upstream`` として追加します。"

#: ../../rst/dev_guide/developing_collections_contributing.rst:48
msgid "Create a branch and commit your changes on the branch."
msgstr "ブランチを作成し、ブランチで変更をコミットします。"

#: ../../rst/dev_guide/developing_collections_contributing.rst:50
msgid "Remember to add tests for your changes, see :ref:`testing_collections`."
msgstr "変更にテストを追加するのを忘れないようにしてください。:ref:`testing_collections` を参照してください。"

#: ../../rst/dev_guide/developing_collections_contributing.rst:52
msgid "Push your changes to your fork of the collection and create a Pull Request."
msgstr "変更をコレクションのフォークにプッシュし、プル要求を作成します。"

#: ../../rst/dev_guide/developing_collections_contributing.rst:54
msgid "You can test your changes by using this checkout of ``community.general`` in playbooks and roles with whichever version of Ansible you have installed locally, including a local checkout of ``ansible/ansible``'s ``devel`` branch."
msgstr "これで、``ansible/ansible`` の ``devel`` ブランチのローカルチェックアウトを含め、ローカルにインストールしたどのバージョンの Ansible でも、Playbook やロールで ``community.general`` のチェックアウトを使用して変更をテストできます。"

#: ../../rst/dev_guide/developing_collections_creating.rst:5
msgid "Creating collections"
msgstr "コレクションの作成"

#: ../../rst/dev_guide/developing_collections_creating.rst:7
msgid "To create a collection:"
msgstr "コレクションを作成するには、以下を行います。"

#: ../../rst/dev_guide/developing_collections_creating.rst:9
msgid "Create a :ref:`collection skeleton<creating_collections_skeleton>` with the ``collection init`` command."
msgstr "``collection init`` コマンドで :ref:`コレクションスケルトン<creating_collections_skeleton>` を作成します。"

#: ../../rst/dev_guide/developing_collections_creating.rst:10
msgid "Add modules and other content to the collection."
msgstr "モジュールおよびその他のコンテンツをコレクションに追加します。"

#: ../../rst/dev_guide/developing_collections_creating.rst:11
msgid "Build the collection into a collection artifact with :ref:`ansible-galaxy collection build<building_collections>`."
msgstr ":ref:`ansible-galaxy collection build<building_collections>` を使用してコレクションをコレクションアーティファクトにビルドします。"

#: ../../rst/dev_guide/developing_collections_creating.rst:12
msgid "Publish the collection artifact to Galaxy with :ref:`ansible-galaxy collection publish<publishing_collections>`."
msgstr ":ref:`ansible-galaxy collection publish<publishing_collections>` で構築したコレクションアーティファクトを Galaxy に公開します。"

#: ../../rst/dev_guide/developing_collections_creating.rst:14
msgid "A user can then install your collection on their systems."
msgstr "これにより、ユーザーが、そのコレクションをシステムにインストールできるようになります。"

#: ../../rst/dev_guide/developing_collections_creating.rst:23
msgid "Creating a collection skeleton"
msgstr "コレクションスケルトンの作成"

#: ../../rst/dev_guide/developing_collections_creating.rst:25
msgid "To start a new collection, run the following command in your collections directory:"
msgstr "新しいコレクションを開始するには、コレクションディレクトリーで以下のコマンドを実行します。"

#: ../../rst/dev_guide/developing_collections_creating.rst:33
msgid "Both the namespace and collection names use the same strict set of requirements. See `Galaxy namespaces <https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespaces>`_ on the Galaxy docsite for those requirements."
msgstr "名前空間とコレクション名はいずれも、同じ厳密な要件セットを使用します。これらの要件については、Galaxy ドキュメントスイートの「`Galaxy 名前空間 <https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespaces>`_」で確認してください。"

#: ../../rst/dev_guide/developing_collections_creating.rst:35
msgid "It will create the structure ``[my_namespace]/[my_collection]/[collection skeleton]``."
msgstr "``[my_namespace]/[my_collection]/[collection skeleton]`` の構造を作成します。"

#: ../../rst/dev_guide/developing_collections_creating.rst:37
msgid "If Git is used for version control, the corresponding repository should be initialized in the collection directory."
msgstr "Git をバージョン管理に使用する場合は、対応するリポジトリーをコレクションディレクトリーで初期化する必要があります。"

#: ../../rst/dev_guide/developing_collections_creating.rst:39
msgid "Once the skeleton exists, you can populate the directories with the content you want inside the collection. See `ansible-collections <https://github.com/ansible-collections/>`_ GitHub Org to get a better idea of what you can place inside a collection."
msgstr "スケルトンが存在すると、コレクション内の内容でディレクトリーを設定できます。`ansible-collections <https://github.com/ansible-collections/>`_ の GitHub Org で、コレクションに配置できる内容を十分に理解することができます。"

#: ../../rst/dev_guide/developing_collections_creating.rst:41
msgid "Reference: the ``ansible-galaxy collection`` command"
msgstr "参照: ``ansible-galaxy collection`` コマンド"

#: ../../rst/dev_guide/developing_collections_creating.rst:43
msgid "Currently the ``ansible-galaxy collection`` command implements the following sub commands:"
msgstr "現在、``ansible-galaxy collection`` コマンドは以下のサブコマンドを実装します。"

#: ../../rst/dev_guide/developing_collections_creating.rst:45
msgid "``init``: Create a basic collection skeleton based on the default template included with Ansible or your own template."
msgstr "``init``: Ansible に含まれるデフォルトテンプレートまたは独自のテンプレートに基づいて、基本的なコレクションのスケルトンを作成します。"

#: ../../rst/dev_guide/developing_collections_creating.rst:46
msgid "``build``: Create a collection artifact that can be uploaded to Galaxy or your own repository."
msgstr "``build``: Galaxy または独自のリポジトリーにアップロードできるコレクションアーティファクトを作成します。"

#: ../../rst/dev_guide/developing_collections_creating.rst:47
msgid "``publish``: Publish a built collection artifact to Galaxy."
msgstr "``publish``: 構築したコレクションアーティファクトを Galaxy に公開します。"

#: ../../rst/dev_guide/developing_collections_creating.rst:48
msgid "``install``: Install one or more collections."
msgstr "``install``: 1 つ以上のコレクションをインストールします。"

#: ../../rst/dev_guide/developing_collections_creating.rst:50
msgid "To learn more about the ``ansible-galaxy`` command-line tool, see the :ref:`ansible-galaxy` man page."
msgstr "``ansible-galaxy`` コマンドラインツールの詳細は、:ref:`ansible-galaxy` の man ページを参照してください。"

#: ../../rst/dev_guide/developing_collections_creating.rst:56
msgid ":ref:`collection_structure`"
msgstr ":ref:`collection_structure`"

#: ../../rst/dev_guide/developing_collections_creating.rst:57
msgid "Directories and files included in the collection skeleton"
msgstr "コレクションスケルトンに含まれるディレクトリーおよびファイル"

#: ../../rst/dev_guide/developing_collections_distributing.rst:5
msgid "Distributing collections"
msgstr "コレクションの配布"

#: ../../rst/dev_guide/developing_collections_distributing.rst:7
msgid "A collection is a distribution format for Ansible content. A typical collection contains modules and other plugins that address a set of related use cases. For example, a collection might automate administering a particular database. A collection can also contain roles and playbooks."
msgstr "コレクションとは、Ansible コンテンツのディストリビューション形式です。典型的なコレクションには、一連の関連するユースケースに対応するモジュールやその他のプラグインが含まれています。例えば、特定のデータベースの管理を自動化するコレクションなどがあります。コレクションには、ロールやPlaybookを含めることもできます。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:9
msgid "To distribute your collection and allow others to use it, you can publish your collection on one or more :term:`distribution server`. Distribution servers include:"
msgstr "コレクションを配信して他の人が使用できるようにするには、1つまたは複数の :term:`distribution server` でコレクションを公開することができます。配信サーバーには次のようなものがあります。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:12
msgid "Distribution server"
msgstr "配信サーバー"

#: ../../rst/dev_guide/developing_collections_distributing.rst:12
msgid "Collections accepted"
msgstr "受け入れ可能なコレクション"

#: ../../rst/dev_guide/developing_collections_distributing.rst:14
msgid "Ansible Galaxy"
msgstr "Ansible Galaxy"

#: ../../rst/dev_guide/developing_collections_distributing.rst:14
msgid "All collections"
msgstr "全コレクション"

#: ../../rst/dev_guide/developing_collections_distributing.rst:15
msgid ":term:`Pulp 3 Galaxy`"
msgstr ":term:`Pulp 3 Galaxy`"

#: ../../rst/dev_guide/developing_collections_distributing.rst:15
msgid "All collections, supports signed collections"
msgstr "すべてのコレクション、署名付きコレクションのサポート"

#: ../../rst/dev_guide/developing_collections_distributing.rst:16
msgid "Red Hat Automation Hub"
msgstr "Red Hat Automation Hub"

#: ../../rst/dev_guide/developing_collections_distributing.rst:16
msgid "Only collections certified by Red Hat, supports signed collections"
msgstr "Red Hat 認定のコレクションのみが署名済みコレクションをサポート。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:17
msgid "Privately hosted Automation Hub"
msgstr "プライベートにホストされるオートメーションハブ"

#: ../../rst/dev_guide/developing_collections_distributing.rst:17
msgid "Collections authorized by the owners"
msgstr "オーナーが許可したコレクション"

#: ../../rst/dev_guide/developing_collections_distributing.rst:20
msgid "Distributing collections involves four major steps:"
msgstr "コレクションを配信するには、大きく分けて4つのステップがあります。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:22
#: ../../rst/dev_guide/developing_collections_distributing.rst:34
msgid "Initial configuration of your distribution server or servers"
msgstr "配信サーバーの初期設定"

#: ../../rst/dev_guide/developing_collections_distributing.rst:23
#: ../../rst/dev_guide/developing_collections_distributing.rst:124
msgid "Building your collection tarball"
msgstr "コレクション tarball のビルド"

#: ../../rst/dev_guide/developing_collections_distributing.rst:24
#: ../../rst/dev_guide/developing_collections_distributing.rst:289
msgid "Preparing to publish your collection"
msgstr "コレクション公開の準備"

#: ../../rst/dev_guide/developing_collections_distributing.rst:25
#: ../../rst/dev_guide/developing_collections_distributing.rst:356
msgid "Publishing your collection"
msgstr "コレクションの公開"

#: ../../rst/dev_guide/developing_collections_distributing.rst:36
msgid "Configure a connection to one or more distribution servers so you can publish collections there. You only need to configure each distribution server once. You must repeat the other steps (building your collection tarball, preparing to publish, and publishing your collection) every time you publish a new collection or a new version of an existing collection."
msgstr "1つまたは複数の配信サーバーへの接続を設定し、そこでコレクションを公開できるようにします。各配信サーバーの設定は、1回だけ行う必要があります。その他の手順（コレクションのtarballのビルド、公開の準備、コレクションの公開）は、新しいコレクションまたは既存のコレクションの新しいバージョンを公開するたびに繰り返す必要があります。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:38
msgid "Create a namespace on each distribution server you want to use."
msgstr "使用する各配信サーバーの名前空間を作成します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:39
msgid "Get an API token for each distribution server you want to use."
msgstr "使用する配信サーバーごとに API トークンを取得します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:40
msgid "Specify the API token for each distribution server you want to use."
msgstr "使用する配信サーバーごとに API トークンを指定します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:45
msgid "Creating a namespace"
msgstr "名前空間の作成"

#: ../../rst/dev_guide/developing_collections_distributing.rst:47
msgid "You must upload your collection into a namespace on each distribution server. If you have a login for Ansible Galaxy, your Ansible Galaxy username is usually also an Ansible Galaxy namespace."
msgstr "コレクションを各配信サーバーの名前空間にアップロードする必要があります。Ansible Galaxyにログインアカウントがある場合、Ansible Galaxyのユーザー名は通常、Ansible Galaxyの名前空間でもあります。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:51
msgid "Namespaces on Ansible Galaxy cannot include hyphens. If you have a login for Ansible Galaxy that includes a hyphen, your Galaxy username is not also a Galaxy namespace. For example, ``awesome-user`` is a valid username for Ansible Galaxy, but it is not a valid namespace."
msgstr "Ansible Galaxyの名前空間には、ハイフンを含めることができません。ハイフンを含むAnsible Galaxyのログインアカウントがある場合、Galaxyのユーザー名はGalaxyの名前空間ではありません。たとえば、``awesome-user`` は、Ansible Galaxy の有効なユーザー名ですが、有効な名前空間ではありません。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:53
msgid "You can create additional namespaces on Ansible Galaxy if you choose. For Red Hat Automation Hub and private Automation Hub you must create a namespace before you can upload your collection. To create a namespace:"
msgstr "必要に応じて、Ansible Galaxy で追加の名前空間を作成できます。Red Hat Automation Hub およびプライベートのオートメーションハブの場合、コレクションをアップロードする前に名前空間を作成する必要があります。名前空間を作成するには、以下の手順を実施します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:55
msgid "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."
msgstr "Galaxy で名前空間を作成するには、Galaxy ドキュメントサイトで「`Galaxy namespaces <https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespaces>`_」を参照して詳細を確認してください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:56
msgid "To create a namespace on Red Hat Automation Hub, see the `Ansible Certified Content FAQ <https://access.redhat.com/articles/4916901>`_."
msgstr "Red Hat Automation Hub で名前空間を作成するには、`Ansible Certified Content FAQ <https://access.redhat.com/articles/4916901>`_ を参照してください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:58
msgid "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`."
msgstr "コレクションごとに :file:`galaxy.yml` ファイルで名前空間を指定します。:file:`galaxy.yml` ファイルの詳細については、:ref:`collections_galaxy_meta` を参照してください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:63
msgid "Getting your API token"
msgstr "API トークンの取得"

#: ../../rst/dev_guide/developing_collections_distributing.rst:65
msgid "An API token authenticates your connection to each distribution server. You need a separate API token for each distribution server. Use the correct API token to connect to each distribution server securely and protect your content."
msgstr "APIトークンは、各配信サーバーに対してコレクションを認証します。APIトークンは、各配信サーバーごとに必要となります。正しいAPIトークンを使用して、各配信サーバーに安全に接続し、コンテンツを保護してください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:67
msgid "To get your API token:"
msgstr "API トークンを取得するには、以下を行います。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:69
msgid "To get an API token for Galaxy, go to the `Galaxy profile preferences <https://galaxy.ansible.com/me/preferences>`_ page and click :guilabel:`API Key`."
msgstr "GalaxyのAPIトークンを取得するには、`Galaxy profile preferences <https://galaxy.ansible.com/me/preferences>`_ ページに移動し、:guilabel:`API Key` をクリックします。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:70
msgid "To get an API token for Automation Hub, go to `the token page <https://cloud.redhat.com/ansible/automation-hub/token/>`_ and click :guilabel:`Load token`."
msgstr "Automation HubのAPIトークンを取得するには、`the token page <https://cloud.redhat.com/ansible/automation-hub/token/>`_ に移動し、:guilabel:`Load token` をクリックします。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:75
msgid "Specifying your API token and distribution server"
msgstr "APIトークンと配信サーバーの指定"

#: ../../rst/dev_guide/developing_collections_distributing.rst:77
msgid "Each time you publish a collection, you must specify the API token and the distribution server to create a secure connection. You have two options for specifying the token and distribution server:"
msgstr "コレクションを公開するたびに、APIトークンと配信サーバーを指定して、安全な接続を行う必要があります。トークンと配信サーバーの指定には2つのオプションがあります。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:79
msgid "You can configure the token in configuration, as part of a ``galaxy_server_list`` entry in your :file:`ansible.cfg` file. Using configuration is the most secure option."
msgstr "トークンの設定は、コンフィギュレーションで、 :file:`ansible.cfg` ファイルの``galaxy_server_list`` エントリの一部として行うことができます。コンフィギュレーションを使用することは、最も安全なオプションです。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:80
msgid "You can pass the token at the command line as an argument to the ``ansible-galaxy`` command. If you pass the token at the command line, you can specify the server at the command line, by using the default setting, or by setting the server in configuration. Passing the token at the command line is insecure, because typing secrets at the command line may expose them to other users on the system."
msgstr "トークンは、``ansible-galaxy`` コマンドの引数として、コマンドラインで渡すことができます。コマンドラインでトークンを渡す場合、デフォルト設定を使用して、またはコンフィグレーションでサーバーを設定して、コマンドラインでサーバーを指定することができます。コマンドラインでトークンを渡すことは安全ではありません。なぜなら、コマンドラインでシークレットを入力すると、システムの他のユーザーにシークレットが漏れる可能性があるからです。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:85
msgid "Specifying the token and distribution server in configuration"
msgstr "コンフィギュレーションでのトークンと配信サーバーの指定"

#: ../../rst/dev_guide/developing_collections_distributing.rst:87
msgid "By default, Ansible Galaxy is configured as the only distribution server. You can add other distribution servers and specify your API token or tokens in configuration by editing the ``galaxy_server_list`` section of your :file:`ansible.cfg` file. This is the most secure way to manage authentication for distribution servers. Specify a URL and token for each server. For example:"
msgstr "デフォルトでは、Ansible Galaxyが唯一の配信サーバーとして設定されています。:file:`ansible.cfg` ファイルの``galaxy_server_list`` セクションを編集することで、他の配信サーバーを追加し、API トークンをコンフィグレーションで指定することができます。これは、配信サーバーの認証を管理する最も安全な方法です。各サーバーのURLとトークンを指定します。例えば、以下のようになります。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:98
msgid "You cannot use ``apt-key`` with any servers defined in your :ref:`galaxy_server_list <galaxy_server_config>`. See :ref:`galaxy_server_config` for complete details."
msgstr "``apt-key`` は、:ref:`galaxy_server_list <galaxy_server_config>` で定義されているサーバーと一緒に使用することはできません。詳細は:ref:`galaxy_server_config` をご覧ください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:103
msgid "Specifying the token at the command line"
msgstr "コマンドラインでのトークンの指定"

#: ../../rst/dev_guide/developing_collections_distributing.rst:105
msgid "You can specify the API token at the command line using the ``--token`` argument of the :ref:`ansible-galaxy` command. There are three ways to specify the distribution server when passing the token at the command line:"
msgstr "APIトークンをコマンドラインで指定するには、:ref:`ansible-galaxy` コマンドの``--token`` 引数を使用します。コマンドラインでトークンを渡す際の配信サーバーの指定方法は3とおりあります。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:107
msgid "using the ``--server`` argument of the :ref:`ansible-galaxy` command"
msgstr ":ref:`ansible-galaxy` コマンドの``--server`` 引数の使用"

#: ../../rst/dev_guide/developing_collections_distributing.rst:108
msgid "relying on the default (https://galaxy.ansible.com)"
msgstr "デフォルトへの依存 (https://galaxy.ansible.com)"

#: ../../rst/dev_guide/developing_collections_distributing.rst:109
msgid "setting a server in configuration by creating a :ref:`GALAXY_SERVER` setting in your :file:`ansible.cfg` file"
msgstr ":file:`ansible.cfg` ファイルへの :ref:`GALAXY_SERVER` 設定の作成によるコンフィギュレーションでのサーバーの設定"

#: ../../rst/dev_guide/developing_collections_distributing.rst:111
#: ../../rst/dev_guide/style_guide/index.rst:222
#: ../../rst/shared_snippets/installing_collections_git_repo.txt:10
msgid "For example:"
msgstr "例:"

#: ../../rst/dev_guide/developing_collections_distributing.rst:119
msgid "Using the ``--token`` argument is insecure. Passing secrets at the command line may expose them to others on the system."
msgstr "``--token`` 引数の使用は安全ではありません。コマンドラインでシークレットを渡すと、システムの他のユーザーにシークレットが漏れる可能性があります。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:126
msgid "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:"
msgstr "1つまたは複数の配信サーバーを設定した後、コレクションのtarballをビルドします。コレクションのtarballは、公開されたアーティファクトであり、お客様がアップロードし、他のユーザーがコレクションをインストールするためにダウンロードするオブジェクトです。コレクションのtarballをビルドするには、以下の手順で行います。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:128
msgid "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`."
msgstr ":file:`galaxy.yml` ファイルのバージョン番号を確認してください。コレクションを公開するたびに、新しいバージョン番号が必要になります。配信サーバー上のコレクションの既存バージョンを変更することはできません。同じコレクションのバージョンを複数回アップロードしようとすると、配信サーバーはエラー``Code: conflict.collection_exists`` を返します。コレクションは、セマンティックバージョニングルールに従います。バージョンの詳細については、:ref:`collection_versions` を参照してください。:file:`galaxy.yml` ファイルの詳細については、:ref:`collections_galaxy_meta` を参照してください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:129
msgid "Run ``ansible-galaxy collection build`` from inside the top-level directory of the collection. For example:"
msgstr "コレクションの最上位ディレクトリの中から``ansible-galaxy collection build`` を実行します。例えば、以下のようになります。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:135
msgid "This command builds a tarball of the collection in the current directory, which you can upload to your selected distribution server::"
msgstr "このコマンドにより、現在のディレクトリーにコレクションの tarball がビルドされます。これを希望する配信サーバーにアップロードできます。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:144
msgid "To reduce the size of collections, certain files and folders are excluded from the collection tarball by default. See :ref:`ignoring_files_and_folders_collections` if your collection directory contains other files you want to exclude."
msgstr "コレクションのサイズを小さくするために、デフォルトではコレクションのtarballから特定のファイルやフォルダが除外されています。コレクションディレクトリに除外したい他のファイルがある場合は、:ref:`ignoring_files_and_folders_collections` を参照してください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:145
msgid "The current Galaxy maximum tarball size is 2 MB."
msgstr "現在の Galaxy の tarball の最大サイズは 2 MB です。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:147
msgid "You can upload your tarball to one or more distribution servers. You can also distribute your collection locally by copying the tarball to install your collection directly on target systems."
msgstr "tarballは、1つまたは複数の配信サーバーにアップロードすることができます。また、コレクションをローカルに配布するには、tarballをコピーしてターゲットシステムにコレクションを直接インストールします。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:153
msgid "Ignoring files and folders"
msgstr "ファイルやフォルダーを無視する"

#: ../../rst/dev_guide/developing_collections_distributing.rst:155
msgid "You can exclude files from your collection with either  :ref:`build_ignore <build_ignore>` or  :ref:`manifest_directives`. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`."
msgstr ":ref:`build_ignore <build_ignore>` または  :ref:`manifest_directives` のいずれかを使用してコレクションからファイルを除外できます。:file:`galaxy.yml` ファイルの詳細は、 :ref:`collections_galaxy_meta` を参照してください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:161
msgid "Include all, with explicit ignores"
msgstr "明示的に無視してすべてを含める"

#: ../../rst/dev_guide/developing_collections_distributing.rst:163
msgid "By default the build step includes all the files in the collection directory in the tarball except for the following:"
msgstr "デフォルトでは、ビルドステップでは、tarball内のコレクションディレクトリにある、以下を除くすべてのファイルが含まれます。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:165
msgid "``galaxy.yml``"
msgstr "``galaxy.yml``"

#: ../../rst/dev_guide/developing_collections_distributing.rst:166
msgid "``*.pyc``"
msgstr "``*.pyc``"

#: ../../rst/dev_guide/developing_collections_distributing.rst:167
msgid "``*.retry``"
msgstr "``*.retry``"

#: ../../rst/dev_guide/developing_collections_distributing.rst:168
msgid "``tests/output``"
msgstr "``tests/output``"

#: ../../rst/dev_guide/developing_collections_distributing.rst:169
msgid "previously built tarballs in the root directory"
msgstr "ルートディレクトリーに以前にビルドされたtarball"

#: ../../rst/dev_guide/developing_collections_distributing.rst:170
msgid "various version control directories such as ``.git/``"
msgstr "``.git/`` などのさまざまなバージョン管理ディレクトリー"

#: ../../rst/dev_guide/developing_collections_distributing.rst:172
msgid "To exclude other files and folders from your collection tarball, set a list of file glob-like patterns in the ``build_ignore`` key in the collection's ``galaxy.yml`` file. These patterns use the following special characters for wildcard matching:"
msgstr "コレクションのtarballから他のファイルおよびディレクトリーを除外するには、コレクションの ``galaxy.yml`` ファイルの ``build_ignore`` キーに、ファイルグロブのようなパターンの一覧を設定します。これらのパターンはワイルドカードの一致に以下の特殊文字を使用します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:174
msgid "``*``: Matches everything"
msgstr "``*``: すべてに一致します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:175
msgid "``?``: Matches any single character"
msgstr "``?``: 任意の単一文字に一致します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:176
msgid "``[seq]``: Matches any character in sequence"
msgstr "``[seq]``:任意の連続した文字に一致します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:177
msgid "``[!seq]``:Matches any character not in sequence"
msgstr "``[!seq]``:連続していない任意の文字に一致します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:179
msgid "For example, to exclude the :file:`sensitive` folder within the ``playbooks`` folder as well any ``.tar.gz`` archives, set the following in your ``galaxy.yml`` file:"
msgstr "たとえば、``playbooks`` ディレクトリー内の :file:`sensitive` ディレクトリーや ``.tar.gz`` アーカイブを除外する場合は、``galaxy.yml`` ファイルに以下を設定します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:188
msgid "The ``build_ignore`` feature is only supported with ``ansible-galaxy collection build`` in Ansible 2.10 or newer."
msgstr "``build_ignore`` 機能は、Ansible 2.10 以降の``ansible-galaxy collection build`` でのみサポートされています。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:194
msgid "Manifest Directives"
msgstr "マニフェストディレクティブ"

#: ../../rst/dev_guide/developing_collections_distributing.rst:198
msgid "The :file:`galaxy.yml` file supports manifest directives that are historically used in Python packaging, as described in `MANIFEST.in commands <https://packaging.python.org/en/latest/guides/using-manifest-in/#manifest-in-commands>`_."
msgstr ":file:`galaxy.yml` ファイルは、`MANIFEST.in commands <https://packaging.python.org/en/latest/guides/using-manifest-in/#manifest-in-commands>`_ で説明されているように、Python パッケージでこれまで使用されていたマニフェストディレクティブをサポートします。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:201
msgid "The use of ``manifest`` requires installing the optional ``distlib`` Python dependency."
msgstr "``manifest`` を使用するには、オプションの ``distlib`` Python 依存関係をインストールする必要があります。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:204
msgid "The ``manifest`` feature is only supported with ``ansible-galaxy collection build`` in ``ansible-core`` 2.14 or newer, and is mutually exclusive with ``build_ignore``."
msgstr "``manifest`` 機能は、``ansible-core`` 2.14 以降の ``ansible-galaxy collection build`` でのみサポートされ、``build_ignore`` と合わせて使用できません。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:206
msgid "For example, to exclude the :file:`sensitive` folder within the ``playbooks`` folder as well as any ``.tar.gz`` archives, set the following in your :file:`galaxy.yml` file:"
msgstr "たとえば、``playbooks`` ディレクトリー内の :file:`sensitive` ディレクトリーや ``.tar.gz`` アーカイブを除外する場合は、:file:`galaxy.yml` ファイルに以下を設定します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:215
msgid "By default, the ``MANIFEST.in`` style directives would exclude all files by default, but there are default directives in place. Those default directives are described below. To see the directives in use during build, pass ``-vvv`` with the ``ansible-galaxy collection build`` command."
msgstr "デフォルトでは、``MANIFEST.in`` スタイルのディレクティブはデフォルトですべてのファイルを除外しますが、デフォルトのディレクティブが配置されています。これらのデフォルトのディレクティブについて以下で説明します。ビルド時に使用するディレクティブを表示するには、``ansible-galaxy collection build`` コマンドで ``-vvv`` を指定します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:249
msgid "``<namespace>-<name>-*.tar.gz`` is expanded with the actual ``namespace`` and ``name``."
msgstr "``<namespace>-<name>-*.tar.gz`` は、実際の ``namespace`` および ``name`` で展開されます。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:251
msgid "The ``manifest.directives`` supplied in :file:`galaxy.yml` are inserted after the default includes and before the default excludes."
msgstr ":file:`galaxy.yml` で指定される ``manifest.directives`` は、デフォルトの includes およびデフォルトの excludes の前に挿入されます。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:253
msgid "To enable the use of manifest directives without supplying your own, insert either ``manifest: {}`` or ``manifest: null`` in the :file:`galaxy.yml` file and remove any use of ``build_ignore``."
msgstr "独自のディレクティブを指定せずにマニフェストディレクティブを使用できるようにするには、：file:`galaxy.yml` ファイルに ``manifest: {}`` または ``manifest: null`` を挿入し、使用されている ``build_ignore`` を削除します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:255
msgid "If the default manifest directives do not meet your needs, you can set ``manifest.omit_default_directives`` to a value of ``true`` in :file:`galaxy.yml`. You then must specify a  full compliment of manifest directives in :file:`galaxy.yml`. The defaults documented above are a good starting point."
msgstr "デフォルトのマニフェストディレクティブが要件に合わない場合には、:file:`galaxy.yml` で ``manifest.omit_default_directives`` の値を ``true`` に指定できます。次に :file:`galaxy.yml` で完全に補完したマニフェストディレクティブを指定する必要があります。出発点として、上記に記載されているようにデフォルトを使用することが適切です。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:257
msgid "Below is an example where the default directives are not included."
msgstr "以下は、デフォルトのディレクティブが含まれていない例です。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:274
msgid "Signing a collection"
msgstr "コレクションの署名"

#: ../../rst/dev_guide/developing_collections_distributing.rst:276
msgid "You can include a GnuPG signature with your collection on a :term:`Pulp 3 Galaxy` server. See `Enabling collection signing <https://galaxyng.netlify.app/config/collection_signing/>`_ for details."
msgstr ":term:`Pulp 3 Galaxy` のご使用のコレクションに GnuPG署名を追加できます。詳細は、`Enabling collection signing <https://galaxyng.netlify.app/config/collection_signing/>`_ を参照してください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:278
msgid "You can manually generate detached signatures for a collection using the ``gpg`` CLI using the following step. This step assume you have generated a GPG private key, but do not cover this process."
msgstr "以下の手順の ``gpg`` CLI を使用してコレクションのデタッチされた署名を手動で生成できます。この手順では GPG 秘密鍵を生成していることを前提としていますが、このプロセスについては説明しません。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:291
msgid "Each time you publish your collection, you must create a :ref:`new version <collection_versions>` on the distribution server. After you publish a version of a collection, you cannot delete or modify that version. To avoid unnecessary extra versions, check your collection for bugs, typos, and other issues locally before publishing:"
msgstr "コレクションを公開するたびに、配信サーバーに:ref:`new version <collection_versions>` を作成する必要があります。コレクションのあるバージョンを公開した後は、そのバージョンを削除したり変更したりすることはできません。不要な追加バージョンを避けるために、コレクションを公開する前にローカルでバグやタイプミスなどの問題をチェックしてください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:293
msgid "Install the collection locally."
msgstr "コレクションをローカルにインストールします。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:294
msgid "Review the locally installed collection before publishing a new version."
msgstr "新しいバージョンを公開する前に、ローカルにインストールされているコレクションを確認してください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:297
msgid "Installing your collection locally"
msgstr "コレクションのローカルインストール"

#: ../../rst/dev_guide/developing_collections_distributing.rst:299
msgid "You have two options for installing your collection locally:"
msgstr "コレクションをローカルにインストールするには、2つの方法があります。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:301
msgid "Install your collection locally from the tarball."
msgstr "コレクションをtarballからローカルにインストールする。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:302
msgid "Install your collection locally from your git repository."
msgstr "gitリポジトリからコレクションをローカルにインストールする。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:305
msgid "Installing your collection locally from the tarball"
msgstr "tarballからのコレクションのローカルインストール"

#: ../../rst/dev_guide/developing_collections_distributing.rst:307
msgid "To install your collection locally from the tarball, run ``ansible-galaxy collection install`` and specify the collection tarball. You can optionally specify a location using the ``-p`` flag. For example:"
msgstr "コレクションをtarballからローカルにインストールするには、``ansible-galaxy collection install`` を実行し、コレクションのtarballを指定します。オプションで``-p`` フラグを使って場所を指定することもできます。例えば、以下のようになります。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:313
msgid "Install the tarball into a directory configured in :ref:`COLLECTIONS_PATHS` so Ansible can easily find and load the collection. If you do not specify a path value, ``ansible-galaxy collection install`` installs the collection in the first path defined in :ref:`COLLECTIONS_PATHS`."
msgstr "Ansibleがコレクションを簡単に見つけてロードできるように、:ref:`COLLECTIONS_PATHS` で設定したディレクトリにtarballをインストールします。パスの値を指定しない場合、``ansible-galaxy collection install`` は、:ref:`COLLECTIONS_PATHS` で定義された最初のパスにコレクションをインストールします。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:318
msgid "Installing your collection locally from a git repository"
msgstr "git リポジトリーからのコレクションのローカルインストール"

#: ../../rst/dev_guide/developing_collections_distributing.rst:320
msgid "To install your collection locally from a git repository, specify the repository and the branch you want to install:"
msgstr "コレクションをgitリポジトリからローカルにインストールするには、インストールしたいリポジトリとブランチを指定します。"

#: ../../rst/shared_snippets/installing_collections_git_repo.txt:1
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: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: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. Use the prefix ``git+``, unless you're using SSH authentication with the user ``git`` (for example, ``git@github.com:ansible-collections/ansible.windows.git``). 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``でSSH認証を使用していない限り、プレフィックス``git+``を使用します(例: ``git@github.com:ansible-collections/ansible.windows.git``)。コンマ区切りの `git コミットのような <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ 構文を使用して、ブランチ、コミット、またはタグを指定できます。"

#: ../../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 "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: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: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 "Each directory in the repository path (one level deep)."
msgstr "リポジトリーパス内の各ディレクトリー（1 レベルの深さ）"

#: ../../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: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: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/dev_guide/developing_collections_distributing.rst:329
msgid "Reviewing your collection"
msgstr "コレクションの確認"

#: ../../rst/dev_guide/developing_collections_distributing.rst:331
msgid "Review the collection:"
msgstr "コレクションを確認します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:333
msgid "Run a playbook that uses the modules and plugins in your collection. Verify that new features and functionality work as expected. For examples and more details see :ref:`Using collections <using_collections>`."
msgstr "コレクションのモジュールやプラグインを使用するPlaybookを実行します。新しい機能が期待通りに動作するかどうかを検証します。例や詳細については、:ref:`Using collections <using_collections>` をご覧ください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:334
msgid "Check the documentation for typos."
msgstr "ドキュメントに誤字脱字がないか確認します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:335
msgid "Check that the version number of your tarball is higher than the latest published version on the distribution server or servers."
msgstr "tarballのバージョン番号が、配信サーバーで公開されている最新のバージョンよりも高いことを確認してください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:336
msgid "If you find any issues, fix them and rebuild the collection tarball."
msgstr "問題が見つかった場合は、それを修正してコレクションのtarballを再ビルドします。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:341
msgid "Understanding collection versioning"
msgstr "コレクションのバージョニングについて"

#: ../../rst/dev_guide/developing_collections_distributing.rst:343
msgid "The only way to change a collection is to release a new version. The latest version of a collection (by highest version number) is the version displayed everywhere in Galaxy and Automation Hub. Users can still download older versions."
msgstr "コレクションを変更する唯一の方法は、新しいバージョンをリリースすることです。(最大バージョン番号による) コレクションの最新バージョンは、Galaxy およびAutomation Hubのあらゆる場所に表示されるバージョンになります。ユーザーは、古いバージョンを引き続きダウンロードできます。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:345
msgid "Follow semantic versioning when setting the version for your collection. In summary:"
msgstr "コレクションのバージョンを設定する際は、セマンティックバージョニングに従ってください。要約すると、以下のとおりです。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:347
msgid "Increment the major version number, ``x`` of ``x.y.z``, for an incompatible API change."
msgstr "互換性のない API 変更の場合:メジャーバージョンのバージョン番号 (例: ``x.y.z`` の ``x``) を増やします。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:348
msgid "Increment the minor version number, ``y`` of ``x.y.z``, for new functionality in a backwards compatible manner (for example new modules/plugins, parameters, return values)."
msgstr "下位互換性のある新機能（例えば、新しいモジュール/プラグイン、パラメータ、戻り値など）の場合:マイナーバージョン番号（``x.y.z`` の``y``）を増やします。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:349
msgid "Increment the patch version number, ``z`` of ``x.y.z``, for backwards compatible bug fixes."
msgstr "後方互換性のあるバグ修正の場合:パッチのバージョン番号（``x.y.z`` の``z``）を増やします。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:351
msgid "Read the official `Semantic Versioning <https://semver.org/>`_ documentation for details and examples."
msgstr "詳細や例については、`Semantic Versioning <https://semver.org/>`_の公式ドキュメントをお読みください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:358
msgid "The last step in distributing your collection is publishing the tarball to Ansible Galaxy, Red Hat Automation Hub, or a privately hosted Automation Hub instance. You can publish your collection in two ways:"
msgstr "コレクションを配布する最後のステップは、Ansible Galaxy、Red Hat Automation Hub、またはプライベートにホストされているオートメーションハブインスタンスに tarball を公開することです。コレクションの公開には2つの方法があります。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:360
msgid "from the command line using the ``ansible-galaxy collection publish`` command"
msgstr "コマンドラインから（``ansible-galaxy collection publish`` コマンドの使用）"

#: ../../rst/dev_guide/developing_collections_distributing.rst:361
msgid "from the website of the distribution server (Galaxy, Automation Hub) itself"
msgstr "配信サーバー（Galaxy、Automation Hub）自体のWebサイトから"

#: ../../rst/dev_guide/developing_collections_distributing.rst:367
msgid "Publishing a collection from the command line"
msgstr "コマンドラインからのコレクションの公開"

#: ../../rst/dev_guide/developing_collections_distributing.rst:369
msgid "To upload the collection tarball from the command line using ``ansible-galaxy``:"
msgstr "``ansible-galaxy`` を使って、コマンドラインからコレクションの tarball をアップロードするには、以下のコマンドを実行します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:377
msgid "This ansible-galaxy command assumes you have retrieved and stored your API token in configuration. See :ref:`galaxy_specify_token` for details."
msgstr "このansible-galaxyコマンドは、APIトークンを取得してコンフィグレーションに保存していることを前提としています。詳細は:ref:`galaxy_specify_token` を参照してください。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:379
msgid "The ``ansible-galaxy collection publish`` command triggers an import process, just as if you uploaded the collection through the Galaxy website. The command waits until the import process completes before reporting the status back. If you want to continue without waiting for the import result, use the ``--no-wait`` argument and manually look at the import progress in your `My Imports <https://galaxy.ansible.com/my-imports/>`_ page."
msgstr "``ansible-galaxy collection publish`` コマンドは、Galaxy の Web サイトでコレクションをアップロードしているのと同様に、インポートプロセスを発生させます。コマンドは、ステータスを報告する前にインポートプロセスが完了するまで待ちます。インポート結果を待たずに続行する場合は、``--no-wait`` 引数を使用して、`My Imports <https://galaxy.ansible.com/my-imports/>`_ ページで手動でインポートの進行状況を確認します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:384
msgid "Publishing a collection from the website"
msgstr "Web サイトからのコレクションの公開"

#: ../../rst/dev_guide/developing_collections_distributing.rst:386
msgid "To publish your collection directly on the Galaxy website:"
msgstr "コレクションを Galaxy の Web サイトに直接公開するには、以下を実行します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:388
msgid "Go to the `My Content <https://galaxy.ansible.com/my-content/namespaces>`_ page, and click the **Add Content** button on one of your namespaces."
msgstr "`My Content <https://galaxy.ansible.com/my-content/namespaces>`_ ページに移動し、名前空間のいずれかの **コンテンツを追加** ボタンをクリックします。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:389
msgid "From the **Add Content** dialogue, click **Upload New Collection**, and select the collection archive file from your local filesystem."
msgstr "**コンテンツの追加** ダイアログから、**新規コレクションのアップロード** をクリックして、ローカルファイルシステムからコレクションのアーカイブファイルを選択します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:391
msgid "When you upload a collection, Ansible always uploads the tarball to the namespace specified in the collection metadata in the ``galaxy.yml`` file, no matter which namespace you select on the website. If you are not an owner of the namespace specified in your collection metadata, the upload request fails."
msgstr "コレクションをアップロードする際、Web サイトで選択した名前空間に関係なく、Ansibleは``galaxy.yml`` ファイルのコレクションメタデータで指定された名前空間にtarballをアップロードします。コレクションメタデータで指定された名前空間の所有者でない場合、アップロードリクエストは失敗します。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:393
msgid "After Galaxy uploads and accepts a collection, the website shows you the **My Imports** page. This page shows import process information. You can review any errors or warnings about your upload there."
msgstr "Galaxyがコレクションをアップロードして受理すると、Web サイトでは**My Imports**ページが表示されます。このページには、インポートプロセス情報が表示されます。ここでは、アップロードに関するエラーや警告を確認することができます。"

#: ../../rst/dev_guide/developing_collections_distributing.rst:399
msgid ":ref:`collections_galaxy_meta`"
msgstr ":ref:`collections_galaxy_meta`"

#: ../../rst/dev_guide/developing_collections_distributing.rst:400
msgid "Table of fields used in the :file:`galaxy.yml` file"
msgstr ":file:`galaxy.yml` ファイルで使用されるフィールドの表"

#: ../../rst/dev_guide/developing_collections_documenting.rst:5
msgid "Documenting collections"
msgstr "コレクションの文書化"

#: ../../rst/dev_guide/developing_collections_documenting.rst:8
msgid "Documenting modules and plugins"
msgstr "ドキュメントのモジュールおよびプラグイン"

#: ../../rst/dev_guide/developing_collections_documenting.rst:10
msgid "Documenting modules is thoroughly documented in :ref:`module_documenting`. Plugins can be documented the same way as modules, that is with ``DOCUMENTATION``, ``EXAMPLES``, and ``RETURN`` blocks."
msgstr "モジュールの文書化については、:ref: で詳しく説明しています。プラグインはモジュールと同じように記載されています (``DOCUMENTATION``、``EXAMPLES`` および ``RETURN`` のブロック)。"

#: ../../rst/dev_guide/developing_collections_documenting.rst:13
msgid "Documenting roles"
msgstr "ロールの文書化"

#: ../../rst/dev_guide/developing_collections_documenting.rst:15
msgid "To document a role, you have to add a role argument spec by creating a file ``meta/argument_specs.yml`` in your role. See :ref:`role_argument_spec` for details. As an example, you can look at `the argument specs file <https://github.com/sensu/sensu-go-ansible/blob/master/roles/install/meta/argument_specs.yml>`_ of the :ref:`sensu.sensu_go.install role <ansible_collections.sensu.sensu_go.install_role>` on GitHub."
msgstr "ロールを文書化するには、ロールに ``meta/argument_specs.yml`` ファイルを作成してロールの引数仕様を追加する必要があります。詳細は :ref:`role_argument_spec` を参照してください。例として、GitHub で :ref:`sensu.sensu_go.install role <ansible_collections.sensu.sensu_go.install_role>` の `the argument specs file <https://github.com/sensu/sensu-go-ansible/blob/master/roles/install/meta/argument_specs.yml>`_ を確認できます。"

#: ../../rst/dev_guide/developing_collections_documenting.rst:20
msgid "Build a docsite with antsibull-docs"
msgstr "antsibull-docs を使用したドキュメントサイトの構築"

#: ../../rst/dev_guide/developing_collections_documenting.rst:22
msgid "You can use `antsibull-docs <https://pypi.org/project/antsibull-docs>`_ to build a Sphinx-based docsite for your collection:"
msgstr "`antsibull-docs <https://pypi.org/project/antsibull-docs>`_ を使用して、コレクションの Sphinx ベースのドキュメントサイトを構築できます。"

#: ../../rst/dev_guide/developing_collections_documenting.rst:24
msgid "Create your collection and make sure you can use it with ansible-core by adding it to your :ref:`COLLECTIONS_PATHS`."
msgstr "コレクションを作成して、:ref:`COLLECTIONS_PATHS` に追加し、ansible-core で使用できます。"

#: ../../rst/dev_guide/developing_collections_documenting.rst:25
msgid "Create a directory ``dest`` and run ``antsibull-docs sphinx-init --use-current --dest-dir dest namespace.name``, where ``namespace.name`` is the name of your collection."
msgstr "ディレクトリー ``dest`` を作成し、``antsibull-docs sphinx-init --use-current --dest-dir dest namespace.name`` を実行します。ここで、``namespace.name`` はコレクションの名前に置き換えます。"

#: ../../rst/dev_guide/developing_collections_documenting.rst:26
msgid "Go into ``dest`` and run ``pip install -r requirements.txt``. You might want to create a venv and activate it first to avoid installing this globally."
msgstr "``dest`` にアクセスし、``pip install -r requirements.txt`` を実行します。これをグローバルにインストールしないように、最初に venv を作成し、アクティベートすることもできます。"

#: ../../rst/dev_guide/developing_collections_documenting.rst:27
msgid "Then run ``./build.sh``."
msgstr "次に、``./build.sh`` を実行します。"

#: ../../rst/dev_guide/developing_collections_documenting.rst:28
msgid "Open ``build/html/index.html`` in a browser of your choice."
msgstr "任意のブラウザーで ``build/html/index.html`` を開きます。"

#: ../../rst/dev_guide/developing_collections_documenting.rst:30
msgid "If you want to add additional documentation to your collection next to the plugin, module, and role documentation, see :ref:`collections_doc_dir`."
msgstr "プラグイン、モジュール、およびロールのドキュメントの横にあるコレクションにドキュメントを追加する場合は、:ref:`collections_doc_dir` を参照してください。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:5
msgid "Migrating Ansible content to a different collection"
msgstr "Ansible コンテンツのコレクションへの移行"

#: ../../rst/dev_guide/developing_collections_migrating.rst:7
msgid "When you move content from one collection to another, for example to extract a set of related modules out of ``community.general`` to create a more focused collection, you must make sure the transition is easy for users to follow."
msgstr "あるコレクションから別のコレクションにコンテンツを移動する場合 (たとえば、関連するモジュールセットを ``community.general`` から抽出して、より重点的に集中化したコレクションを作成するには)、ユーザーが簡単に移行できるようにする必要があります。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:14
msgid "Migrating content"
msgstr "コンテンツの移行"

#: ../../rst/dev_guide/developing_collections_migrating.rst:16
msgid "Before you start migrating content from one collection to another, look at `Ansible Collection Checklist <https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst>`_."
msgstr "あるコレクションから別のコレクションにコンテンツの移行を開始する前に、`Ansible コレクションチェックリスト <https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst>`_ を参照してください。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:18
msgid "To migrate content from one collection to another, if the collections are parts of `Ansible distribution <https://github.com/ansible-community/ansible-build-data/blob/main/2.10/ansible.in>`_:"
msgstr "コレクションが `Ansible ディストリビューション <https://github.com/ansible-community/ansible-build-data/blob/main/2.10/ansible.in>`_ の一部である場合、コレクションを別のコレクションに移行するには、以下を実行します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:20
msgid "Copy content from the source (old) collection to the target (new) collection."
msgstr "ソース (以前の) コレクションからターゲット (新しい) コレクションにコンテンツをコピーします。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:21
msgid "Deprecate the module/plugin with ``removal_version`` scheduled for the next major version in ``meta/runtime.yml`` of the old collection. The deprecation must be released after the copied content has been included in a release of the new collection."
msgstr "古いコレクションの ``meta/runtime.yml`` の次のメジャーバージョンに予定されている ``removal_version`` でモジュール/プラグインが非推奨になりました。コピーされたコンテンツが新しいコレクションのリリースにあった後に、非推奨がリリースする必要があります。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:22
msgid "When the next major release of the old collection is prepared:"
msgstr "古いコレクションの次のメジャーリリースが準備されている場合は、以下のようになります。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:24
msgid "remove the module/plugin from the old collection"
msgstr "古いコレクションからモジュール/プラグインを削除します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:25
msgid "remove the symlink stored in ``plugin/modules`` directory if appropriate (mainly when removing from ``community.general`` and ``community.network``)"
msgstr "必要に応じて、``plugin/modules`` ディレクトリーに保存されたシンボリックリンクを削除します (主に ``community.general`` および ``community.network``から削除する場合)。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:26
msgid "remove related unit and integration tests"
msgstr "関連するユニットテストおよび統合テストを削除します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:27
msgid "remove specific module utils"
msgstr "特定のモジュールユーティリティーを削除します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:28
msgid "remove specific documentation fragments if there are any in the old collection"
msgstr "古いコレクションにある場合は、特定のドキュメントフラグメントを削除します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:29
msgid "add a changelog fragment containing entries for ``removed_features`` and ``breaking_changes``; you can see an example of a changelog fragment in this `pull request <https://github.com/ansible-collections/community.general/pull/1304>`_"
msgstr "``removed_features`` および ``breaking_changes`` のエントリーを含む変更ログフラグメントを追加します。この `プル要求 <https://github.com/ansible-collections/community.general/pull/1304>`_ で変更ログフラグメントの例を確認できます。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:30
msgid "change ``meta/runtime.yml`` in the old collection:"
msgstr "古いコレクションの ``meta/runtime.yml`` を変更します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:32
msgid "add ``redirect`` to the corresponding module/plugin's entry"
msgstr "対応するモジュール/プラグインのエントリーに ``redirect`` を追加します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:33
msgid "in particular, add ``redirect`` for the removed module utils and documentation fragments if applicable"
msgstr "特に、削除されたモジュールユーティリティーおよびドキュメントフラグメント (該当する場合) に ``redirect`` を追加します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:34
msgid "remove ``removal_version`` from there"
msgstr "そこから ``removal_version`` を削除します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:35
msgid "remove related entries from ``tests/sanity/ignore.txt`` files if exist"
msgstr "``tests/sanity/ignore.txt`` ファイルから関連エントリーが存在する場合は削除します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:36
msgid "remove changelog fragments for removed content that are not yet part of the changelog (in other words, do not modify `changelogs/changelog.yaml` and do not delete files mentioned in it)"
msgstr "変更ログの一部ではない削除されたコンテンツの変更ログフラグメントを削除します (つまり、`changelogs/changelog.yaml` を変更せず、そのファイルに記述されているファイルを削除しないでください)。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:37
msgid "remove requirements that are no longer required in ``tests/unit/requirements.txt``, ``tests/requirements.yml`` and ``galaxy.yml``"
msgstr "``tests/unit/requirements.txt``、``tests/requirements.yml``、および ``galaxy.yml`` ではなくなった要件を削除します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:39
msgid "To implement these changes, you need to create at least three PRs:"
msgstr "以下の変更を実装するには、少なくとも 3 つの PR を作成する必要があります。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:41
msgid "Create a PR against the new collection to copy the content."
msgstr "新しいコレクションに対して PR を作成し、コンテンツをコピーします。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:42
msgid "Deprecate the module/plugin in the old collection."
msgstr "古いコレクションのモジュール/プラグインが非推奨になります。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:43
msgid "Later create a PR against the old collection to remove the content according to the schedule."
msgstr "後に、古いコレクションに対して PR を作成し、スケジュールに応じてコンテンツを削除します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:47
msgid "Adding the content to the new collection"
msgstr "新しいコレクションへのコンテンツの追加"

#: ../../rst/dev_guide/developing_collections_migrating.rst:49
msgid "Create a PR in the new collection to:"
msgstr "新しいコレクションで PR を作成し、以下を行います。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:51
msgid "Copy ALL the related files from the old collection."
msgstr "古いコレクションから関連ファイルをすべてコピーします。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:52
msgid "If it is an action plugin, include the corresponding module with documentation."
msgstr "アクションプラグインの場合は、対応するモジュールとドキュメントを含めます。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:53
msgid "If it is a module, check if it has a corresponding action plugin that should move with it."
msgstr "モジュールの場合は、対応するアクションプラグインがあり、一緒に移動する必要があるかどうかを確認します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:54
msgid "Check ``meta/`` for relevant updates to ``runtime.yml`` if it exists."
msgstr "``meta/`` で、``runtime.yml`` に対する関連更新が存在する場合は、それを確認します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:55
msgid "Carefully check the moved ``tests/integration`` and ``tests/units`` and update for FQCN."
msgstr "移動した ``tests/integration`` および ``tests/units`` を注意して確認し、FQCN を更新してください。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:56
msgid "Review ``tests/sanity/ignore-*.txt`` entries in the old collection."
msgstr "古いコレクションの ``tests/sanity/ignore-*.txt`` エントリーを確認します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:57
msgid "Update ``meta/runtime.yml`` in the old collection."
msgstr "古いコレクションの ``meta/runtime.yml`` を更新します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:61
msgid "Removing the content from the old collection"
msgstr "古いコレクションからのコンテンツの削除"

#: ../../rst/dev_guide/developing_collections_migrating.rst:63
msgid "Create a PR against the source collection repository to remove the modules, module_utils, plugins, and docs_fragments related to this migration:"
msgstr "ソースコレクションリポジトリーに対して PR を作成し、この移行に関連するモジュール、モジュールユーティリティー、プラグイン、およびドキュメントフラグメントを削除します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:65
msgid "If you are removing an action plugin, remove the corresponding module that contains the documentation."
msgstr "アクションプラグインを削除する場合は、ドキュメントが含まれる対応するモジュールを削除します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:66
msgid "If you are removing a module, remove any corresponding action plugin that should stay with it."
msgstr "モジュールを削除する場合は、モジュールに対応するアクションプラグインを削除してください。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:67
msgid "Remove any entries about removed plugins from ``meta/runtime.yml``. Ensure they are added into the new repo."
msgstr "削除されたプラグインに関するエントリーを ``meta/runtime.yml`` から削除します。それらが新しいリポジトリーに追加されるようにしてください。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:68
msgid "Remove sanity ignore lines from ``tests/sanity/ignore\\*.txt``"
msgstr "``tests/sanity/ignore\\*.txt`` から、sanity ignore (健常性の無視) の行を削除します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:69
msgid "Remove associated integration tests from ``tests/integrations/targets/`` and unit tests from ``tests/units/plugins/``."
msgstr "関連する統合テストを ``tests/units/plugins/`` から削除し、``tests/integrations/targets/`` およびユニットテストから削除します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:70
msgid "if you are removing from content from ``community.general`` or ``community.network``, remove entries from ``.github/BOTMETA.yml``."
msgstr "``community.general`` または ``community.network`` からコンテンツを削除すると、``.github/BOTMETA.yml`` からエントリーを削除します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:71
msgid "Carefully review ``meta/runtime.yml`` for any entries you may need to remove or update, in particular deprecated entries."
msgstr "特定の非推奨のエントリーで削除または更新が必要になる可能性のあるエントリーについては、``meta/runtime.yml`` を慎重に確認してください。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:72
msgid "Update ``meta/runtime.yml`` to contain redirects for EVERY PLUGIN, pointing to the new collection name."
msgstr "``meta/runtime.yml`` を更新して、新しいコレクション名を示す EVERY PLUGIN のリダイレクトを追加します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:76
msgid "Maintainers for the old collection have to make sure that the PR is merged in a way that it does not break user experience and semantic versioning:"
msgstr "古いコレクションのメンテナーは、PR がユーザーエクスペリエンスとセマンティックバージョニングを壊さない方法でマージされるようにする必要があります。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:78
msgid "A new version containing the merged PR must not be released before the collection the content has been moved to has been released again, with that content contained in it. Otherwise the redirects cannot work and users relying on that content will experience breakage."
msgstr "マージされた PR を含む新しいバージョンは、コンテンツが移動されたコレクションが再びリリースされる前にリリースされてはならず、そのコンテンツが含まれています。そうしないと、リダイレクトが機能せず、そのコンテンツに依存している場合は破損が発生する可能性があります。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:79
msgid "Once 1.0.0 of the collection from which the content has been removed has been released, such PRs can only be merged for a new **major** version (in other words, 2.0.0, 3.0.0, and so on)."
msgstr "コンテンツが削除されたコレクションで 1.0.0 がリリースされると、この PR は新しい **メジャー** バージョン (つまり 2.0.0、3.0.0 など) のみをマージできます。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:83
msgid "Updating BOTMETA.yml"
msgstr "BOTMETA.yml の更新"

#: ../../rst/dev_guide/developing_collections_migrating.rst:85
msgid "The ``BOTMETA.yml``, for example in `community.general collection repository <https://github.com/ansible-collections/community.general/blob/main/.github/BOTMETA.yml>`_, is the source of truth for:"
msgstr "``BOTMETA.yml`` (たとえば `community.general collection repository <https://github.com/ansible-collections/community.general/blob/main/.github/BOTMETA.yml>`_) は、以下の信頼できるソースです。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:87
msgid "ansibullbot"
msgstr "ansibullbot"

#: ../../rst/dev_guide/developing_collections_migrating.rst:89
msgid "If the old and/or new collection has ``ansibullbot``, its ``BOTMETA.yml`` must be updated correspondingly."
msgstr "古いコレクションまたは新しいコレクションで ``ansibullbot`` がある場合は、それに応じて ``BOTMETA.yml`` を更新する必要があります。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:91
msgid "Ansibulbot will know how to redirect existing issues and PRs to the new repo. The build process for docs.ansible.com will know where to find the module docs."
msgstr "Ansibulbot は、既存の問題と PR を新しいリポジトリーにリダイレクトする方法を認識します。docs.ansible.com のビルドプロセスは、モジュール文書の検索場所を認識します。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:110
msgid "`Example PR <https://github.com/ansible/ansible/pull/66981/files>`_"
msgstr "`PR の例 <https://github.com/ansible/ansible/pull/66981/files>`_"

#: ../../rst/dev_guide/developing_collections_migrating.rst:112
msgid "The ``migrated_to:`` key must be added explicitly for every *file*. You cannot add ``migrated_to`` at the directory level. This is to allow module and plugin webdocs to be redirected to the new collection docs."
msgstr "``migrated_to:`` キーは、*ファイル* ごとに明示的に追加する必要があります。ディレクトリーレベルで ``migrated_to`` を追加することはできません。モジュールとプラグインの Web ドキュメントを新しいコレクションにリダイレクトすることです。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:113
msgid "``migrated_to:`` MUST be added for every:"
msgstr "以下のすべてに ``migrated_to:`` を追加する必要があります。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:115
#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "module"
msgstr "モジュール"

#: ../../rst/dev_guide/developing_collections_migrating.rst:116
msgid "plugin"
msgstr "プラグイン"

#: ../../rst/dev_guide/developing_collections_migrating.rst:117
#: ../../rst/dev_guide/developing_collections_structure.rst:104
msgid "module_utils"
msgstr "モジュールユーティリティー"

#: ../../rst/dev_guide/developing_collections_migrating.rst:118
msgid "contrib/inventory script"
msgstr "contrib/inventory スクリプト"

#: ../../rst/dev_guide/developing_collections_migrating.rst:120
msgid "You do NOT need to add ``migrated_to`` for:"
msgstr "以下に ``migrated_to`` を追加する必要はありません。"

#: ../../rst/dev_guide/developing_collections_migrating.rst:122
msgid "Unit tests"
msgstr "ユニットテスト"

#: ../../rst/dev_guide/developing_collections_migrating.rst:123
#: ../../rst/dev_guide/testing_integration.rst:7
msgid "Integration tests"
msgstr "統合テスト"

#: ../../rst/dev_guide/developing_collections_migrating.rst:124
msgid "ReStructured Text docs (anything under ``docs/docsite/rst/``)"
msgstr "再構築されたテキストドキュメント (``docs/docsite/rst/`` の下すべて)"

#: ../../rst/dev_guide/developing_collections_migrating.rst:125
msgid "Files that never existed in ``ansible/ansible:devel``"
msgstr "``ansible/ansible:devel`` に存在しないファイル"

#: ../../rst/dev_guide/developing_collections_shared.rst:5
msgid "Using shared resources in collections"
msgstr "コレクションで共有リソースの使用"

#: ../../rst/dev_guide/developing_collections_shared.rst:7
msgid "Although developing Ansible modules contained in collections is similar to developing standalone Ansible modules, you use shared resources like documentation fragments and module utilities differently in collections. You can use documentation fragments within and across collections. You can use optional module utilities to support multiple versions of ansible-core in your collection. Collections can also depend on other collections."
msgstr "コレクションに含まれる Ansible モジュールの開発はスタンドアロンの Ansible モジュールの開発に似ていますが、コレクションではドキュメントフラグメントやモジュールユーティリティーなどの共有リソースを異なる方法で使用します。コレクション内およびコレクション間でドキュメントフラグメントを使用できます。任意のモジュールユーティリティーを使用して、コレクション内の複数のバージョンの ansible-core をサポートできます。コレクションが他のコレクションに依存することもあります。"

#: ../../rst/dev_guide/developing_collections_shared.rst:16
msgid "Using documentation fragments in collections"
msgstr "コレクションでのドキュメントフラグメントの使用"

#: ../../rst/dev_guide/developing_collections_shared.rst:18
msgid "To include documentation fragments in your collection:"
msgstr "コレクションにドキュメントフラグメントを含めるには、以下を行います。"

#: ../../rst/dev_guide/developing_collections_shared.rst:20
msgid "Create the documentation fragment: ``plugins/doc_fragments/fragment_name``."
msgstr "ドキュメントフラグメントを作成します (``plugins/doc_fragments/fragment_name``)。"

#: ../../rst/dev_guide/developing_collections_shared.rst:22
msgid "Refer to the documentation fragment with its FQCN."
msgstr "FQCN を含むドキュメントフラグメントを参照してください。"

#: ../../rst/dev_guide/developing_collections_shared.rst:32
msgid ":ref:`module_docs_fragments` covers the basics for documentation fragments. The `kubernetes.core <https://github.com/ansible-collections/kubernetes.core>`_ collection includes a complete example."
msgstr ":ref:`module_docs_fragments` は、ドキュメントフラグメントの基本を説明します。`kubernetes.core <https://github.com/ansible-collections/kubernetes.core>`_ コレクションには完全な例が含まれています。"

#: ../../rst/dev_guide/developing_collections_shared.rst:34
msgid "If you use FQCN, you can use documentation fragments from one collection in another collection."
msgstr "FQCN を使用する場合は、別のコレクションで 1 つのコレクションからドキュメントフラグメントを使用できます。"

#: ../../rst/dev_guide/developing_collections_shared.rst:39
msgid "Leveraging optional module utilities in collections"
msgstr "コレクションでの任意のモジュールユーティリティーの活用"

#: ../../rst/dev_guide/developing_collections_shared.rst:41
msgid "Optional module utilities let you adopt the latest features from the most recent ansible-core release in your collection-based modules without breaking your collection on older Ansible versions. With optional module utilities, you can use the latest features when running against the latest versions, while still providing fallback behaviors when running against older versions."
msgstr "任意のモジュールユーティリティーを使用すると、古い Ansible バージョンのコレクションを壊すことなく、collection-base モジュールで最新の ansible-core リリースの最新機能を採用できます。任意のモジュールユーティリティーを使用すると、最新バージョンに対して実行する場合に最新の機能を利用でき、古いバージョンに対して実行する場合でもフォールバック動作を提供できます。"

#: ../../rst/dev_guide/developing_collections_shared.rst:43
msgid "This implementation, widely used in Python programming, wraps optional imports in conditionals or defensive `try/except` blocks, and implements fallback behaviors for missing imports. Ansible's module payload builder supports these patterns by treating any module_utils import nested in a block (e.g., `if`, `try`) as optional. If the requested import cannot be found during the payload build, it is simply omitted from the target payload and assumed that the importing code will handle its absence at runtime. Missing top-level imports of module_utils packages (imports that are not wrapped in a block statement of any kind) will fail the module payload build, and will not execute on the target."
msgstr "この実装は Python プログラミングで広く使用され、条件または限定された `try/except` ブロックで任意のインポートをラップし、不足しているインポートのフォールバック動作を実装します。Ansible のモジュールペイロードビルダーは、ブロックでネストされた module_utils インポート (例: `if`、`try`) をオプションとして扱うことにより、これらのパターンをサポートします。ペイロードビルド時に要求されたインポートが見つからなかった場合、これはターゲットペイロードから省略され、インポートコードがランタイム時に処理されないことが仮定されます。module_utils パッケージのトップレベルのインポート (あらゆる種類のブロックステートメントでラップされていないインポート) はモジュールペイロードビルドに失敗し、ターゲットでは実行されません。"

#: ../../rst/dev_guide/developing_collections_shared.rst:45
msgid "For example, the `ansible.module_utils.common.respawn` package is only available in Ansible 2.11 and higher. The following module code would fail during the payload build on Ansible 2.10 or earlier (as the requested Python module does not exist, and is not wrapped in a block to signal to the payload builder that it can be omitted from the module payload):"
msgstr "たとえば、`ansible.module_utils.common.respawn` パッケージは Ansible 2.11 以降でしか利用することができません。以下のモジュールコードは Ansible 2.10 以前でのペイロードビルド中に失敗します (要求された Python モジュールが存在せず、モジュールペイロードから省略できることをペイロードビルダーに通知するブロックにラップされていないため)。"

#: ../../rst/dev_guide/developing_collections_shared.rst:51
msgid "By wrapping the import statement in a ``try`` block, the payload builder will omit the Python module if it cannot be located, and assume that the Ansible module will handle it at runtime:"
msgstr "``try`` ブロックで import ステートメントをラップすることで、ペイロードビルダーは、Python モジュールが見つからないと Python モジュールを省略し、Ansible モジュールがランタイム時に処理することを想定します。"

#: ../../rst/dev_guide/developing_collections_shared.rst:66
msgid "The optional import behavior also applies to module_utils imported from collections."
msgstr "任意のインポート動作は、コレクションからインポートされたモジュールユーティリティーにも適用されます。"

#: ../../rst/dev_guide/developing_collections_shared.rst:71
msgid "Listing collection dependencies"
msgstr "コレクションの依存関係の一覧表示"

#: ../../rst/dev_guide/developing_collections_shared.rst:73
msgid "We recommend that collections work as standalone, independent units, depending only on ansible-core. However, if your collection must depend on features and functionality from another collection, list the other collection or collections under ``dependencies`` in your collection's :file:`galaxy.yml` file. Use the :file:`meta/runtime.yml` file to set the ansible-core version that your collection depends on. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`."
msgstr "コレクションはスタンドアロンの独立したユニットとして動作し、ansible-coreにのみ依存することをお勧めします。しかし、コレクションが他のコレクションの機能に依存しなければならない場合は、コレクションの :file:`galaxy.yml` ファイルの``dependencies`` セクションに、他のコレクションをリストアップしてください。コレクションが依存する ansible-core バージョンを設定するには、:file:`meta/runtime.yml` ファイルを使用します。:file:`galaxy.yml` ファイルの詳細については、:ref:`collections_galaxy_meta` を参照してください。"

#: ../../rst/dev_guide/developing_collections_shared.rst:75
msgid "You can use git repositories for collection dependencies during local development and testing. For example:"
msgstr "ローカルでの開発やテストの際に、コレクションの依存関係用にgitリポジトリを使用することができます。以下に例を示します。"

#: ../../rst/dev_guide/developing_collections_structure.rst:5
msgid "Collection structure"
msgstr "コレクション構造"

#: ../../rst/dev_guide/developing_collections_structure.rst:7
msgid "A collection is a simple data structure. None of the directories are required unless you have specific content that belongs in one of them. A collection does require a ``galaxy.yml`` file at the root level of the collection. This file contains all of the metadata that Galaxy and other tools need in order to package, build and publish the collection."
msgstr "コレクションは簡単なデータ構造です。それらの中の 1 つに属する特定のコンテンツがない限り、ディレクトリーは必要ありません。コレクションのルートレベルで ``galaxy.yml`` ファイルが必要になります。このファイルには、Galaxy やその他のツールがコレクションをパッケージ化、ビルド、公開するのに必要なメタデータがすべて含まれます。"

#: ../../rst/dev_guide/developing_collections_structure.rst:14
msgid "Collection directories and files"
msgstr "コレクションディレクトリーおよびファイル"

#: ../../rst/dev_guide/developing_collections_structure.rst:16
msgid "A collection can contain these directories and files:"
msgstr "コレクションには、これらのディレクトリーおよびファイルを含めることができます。"

#: ../../rst/dev_guide/developing_collections_structure.rst:43
msgid "Ansible only accepts ``.md`` extensions for the :file:`README` file and any files in the :file:`/docs` folder."
msgstr "Ansible は、:file:`README` ファイルおよび :file:`/docs` フォルダー内のすべてのファイルの ``.md`` 拡張子のみを受け入れます。"

#: ../../rst/dev_guide/developing_collections_structure.rst:44
msgid "See the `ansible-collections <https://github.com/ansible-collections/>`_ GitHub Org for examples of collection structure."
msgstr "コレクション構造の例は、`ansible-collections <https://github.com/ansible-collections/>`_ GitHub Org を参照してください。"

#: ../../rst/dev_guide/developing_collections_structure.rst:45
msgid "Not all directories are currently in use. Those are placeholders for future features."
msgstr "現在、すべてのディレクトリーが使用されているわけではありません。これらは、将来の機能のプレースホルダーです。"

#: ../../rst/dev_guide/developing_collections_structure.rst:50
msgid "galaxy.yml"
msgstr "galaxy.yml"

#: ../../rst/dev_guide/developing_collections_structure.rst:52
msgid "A collection must have a ``galaxy.yml`` file that contains the necessary information to build a collection artifact. See :ref:`collections_galaxy_meta` for details."
msgstr "コレクションには、コレクションアーティファクトを構築するために必要な情報が含まれる ``galaxy.yml`` ファイルが必要です。詳細は、「:ref:`collections_galaxy_meta`」を参照してください。"

#: ../../rst/dev_guide/developing_collections_structure.rst:57
msgid "docs directory"
msgstr "docs ディレクトリー"

#: ../../rst/dev_guide/developing_collections_structure.rst:59
msgid "Use the ``docs`` folder to describe how to use the roles and plugins the collection provides, role requirements, and so on."
msgstr "``docs`` フォルダを使用して、コレクションが提供するロールとプラグインの使用方法、ロールの要件などを説明します。"

#: ../../rst/dev_guide/developing_collections_structure.rst:61
msgid "For certified collections, Automation Hub displays documents written in markdown in the main ``docs`` directory with no subdirectories. This will not display on https://docs.ansible.com."
msgstr "認定されたコレクションでは、Automation Hubは、サブディレクトリを持たないメインの``docs`` ディレクトリにマークダウンで書かれたドキュメントを表示します。これは、https://docs.ansible.com.には表示されません。"

#: ../../rst/dev_guide/developing_collections_structure.rst:63
msgid "For community collections included in the Ansible PyPI package, docs.ansible.com displays documents written in reStructuredText (.rst) in a docsite/rst/ subdirectory. Define the structure of your extra documentation in ``docs/docsite/extra-docs.yml``:"
msgstr "AnsibleのPyPIパッケージに含まれるコミュニティコレクションの場合、docs.ansible.comはreStructuredText（.rst）で書かれたドキュメントをdocsite/rst/サブディレクトリに表示します。``docs/docsite/extra-docs.yml`` で追加ドキュメントの構造を定義します。"

#: ../../rst/dev_guide/developing_collections_structure.rst:73
msgid "The index page of the documentation for your collection displays the title you define in ``docs/docsite/extra-docs.yml`` with a link to your extra documentation. For an example, see the `community.docker collection repo <https://github.com/ansible-collections/community.docker/tree/main/docs/docsite>`_ and the `community.docker collection documentation <https://docs.ansible.com/ansible/latest/collections/community/docker/index.html>`_."
msgstr "コレクションのドキュメントのインデックスページには、``docs/docsite/extra-docs.yml`` で定義したタイトルと、追加ドキュメントへのリンクが表示されます。例としては、`community.docker collection repo <https://github.com/ansible-collections/community.docker/tree/main/docs/docsite>`_ と`community.docker collection documentation <https://docs.ansible.com/ansible/latest/collections/community/docker/index.html>`_ を参照してください。"

#: ../../rst/dev_guide/developing_collections_structure.rst:75
msgid "You can add extra links to your collection index page and plugin pages with the ``docs/docsite/links.yml`` file. This populates the links under `Description and Communications <https://docs.ansible.com/ansible/devel/collections/community/dns/index.html#plugins-in-community-dns>`_ headings as well as links at the end of the individual plugin pages. See the `collection_template links.yml file <https://github.com/ansible-collections/collection_template/blob/main/docs/docsite/links.yml>`_ for a complete description of the structure and use of this file to create links."
msgstr "コレクションインデックスページおよびプラグインページに、``docs/docsite/links.yml`` ファイルを使用してリンクを追加できます。この方法で、`Description and Communications <https://docs.ansible.com/ansible/devel/collections/community/dns/index.html#plugins-in-community-dns>`_ の見出しの下と、個別のプラグインページの最後にリンクが追加されます。構造の詳細な説明と、ファイルを使用したリンクの作成方法については、`collection_template links.yml file <https://github.com/ansible-collections/collection_template/blob/main/docs/docsite/links.yml>`_ を参照してください。"

#: ../../rst/dev_guide/developing_collections_structure.rst:78
msgid "Plugin and module documentation"
msgstr "プラグインとモジュールのドキュメント"

#: ../../rst/dev_guide/developing_collections_structure.rst:80
msgid "Keep the specific documentation for plugins and modules embedded as Python docstrings. Use ``ansible-doc`` to view documentation for plugins inside a collection:"
msgstr "Python ドキュメント文字列として埋め込まれたプラグインおよびモジュールに関する特定のドキュメントを保持します。コレクション内のプラグインのドキュメントを表示するには``ansible-doc`` を使用してください。"

#: ../../rst/dev_guide/developing_collections_structure.rst:86
msgid "The ``ansible-doc`` command requires the fully qualified collection name (FQCN) to display specific plugin documentation. In this example, ``my_namespace`` is the Galaxy namespace and ``my_collection`` is the collection name within that namespace."
msgstr "特定のプラグインのドキュメントを表示するには、``ansible-doc`` コマンドに完全修飾コレクション名 (FQCN) が必要です。この例では、``my_namespace`` は Galaxy 名前空間となり、``my_collection`` はその名前空間内のコレクション名となります。"

#: ../../rst/dev_guide/developing_collections_structure.rst:88
msgid "The Galaxy namespace of an Ansible collection is defined in the ``galaxy.yml`` file. It can be different from the GitHub organization or repository name."
msgstr "Ansible コレクションの Galaxy 名前空間は ``galaxy.yml`` ファイルで定義されます。GitHub の組織またはリポジトリー名とは異なる場合があります。"

#: ../../rst/dev_guide/developing_collections_structure.rst:93
msgid "plugins directory"
msgstr "plugins ディレクトリー"

#: ../../rst/dev_guide/developing_collections_structure.rst:95
msgid "Add a 'per plugin type' specific subdirectory here, including ``module_utils`` which is usable not only by modules, but by most plugins by using their FQCN. This is a way to distribute modules, lookups, filters, and so on without having to import a role in every play."
msgstr "「プラグインタイプごと」の特有サブディレクトリーをここに追加します。これには、その FQCN を使用して、モジュールでだけでなくほとんどのプラグインで使用できる ``module_utils`` が含まれます。これは、すべてのプレイでロールをインポートすることなくモジュール、検索、フィルターなどを分散する方法です。"

#: ../../rst/dev_guide/developing_collections_structure.rst:97
msgid "Vars plugins in collections are not loaded automatically, and always require being explicitly enabled by using their fully qualified collection name. See :ref:`enable_vars` for details."
msgstr "コレクションの vars プラグインは自動的に読み込まれず、完全修飾コレクション名を使用して常に明示的に有効にする必要があります。詳細は、:ref:`enable_vars` を参照してください。"

#: ../../rst/dev_guide/developing_collections_structure.rst:99
msgid "Cache plugins in collections may be used for fact caching, but are not supported for inventory plugins."
msgstr "コレクションのキャッシュプラグインは、ファクトキャッシュに使用できますが、inventory プラグインではサポートされていません。"

#: ../../rst/dev_guide/developing_collections_structure.rst:106
msgid "When coding with ``module_utils`` in a collection, the Python ``import`` statement needs to take into account the FQCN along with the ``ansible_collections`` convention. The resulting Python import will look like ``from ansible_collections.{namespace}.{collection}.plugins.module_utils.{util} import {something}``"
msgstr "コレクションで ``module_utils`` を使用してコーディングする場合、Python の ``import`` ステートメントは ``ansible_collections`` 規則とともに FQCN を考慮する必要があります。作成される Python インポートは ``from ansible_collections.{namespace}.{collection}.plugins.module_utils.{util} import {something}`` のようになります。"

#: ../../rst/dev_guide/developing_collections_structure.rst:108
msgid "The following example snippets show a Python and PowerShell module using both default Ansible ``module_utils`` and those provided by a collection. In this example the namespace is ``community``, the collection is ``test_collection``. In the Python example the ``module_util`` in question is called ``qradar`` such that the FQCN is ``community.test_collection.plugins.module_utils.qradar``:"
msgstr "以下のスニペットの例は、デフォルトの Ansible ``module_utils`` と、コレクションの両方を使用する Python および PowerShell モジュールを示しています。この例では、名前空間は ``community`` で、コレクションは ``test_collection`` です。Python の例では、問題の ``module_util`` は ``qradar`` と呼ばれ、FQCN が ``community.test_collection.plugins.module_utils.qradar`` となっています。"

#: ../../rst/dev_guide/developing_collections_structure.rst:138
msgid "Note that importing something from an ``__init__.py`` file requires using the file name:"
msgstr "``__init__.py`` ファイルから何かをインポートする場合は、ファイル名を使用する必要があることに注意してください。"

#: ../../rst/dev_guide/developing_collections_structure.rst:144
msgid "In the PowerShell example the ``module_util`` in question is called ``hyperv`` such that the FQCN is ``community.test_collection.plugins.module_utils.hyperv``:"
msgstr "PowerShell の例では、問題の ``module_util`` は ``hyperv`` と呼ばれ、FQCN が ``community.test_collection.plugins.module_utils.hyperv`` となっています。"

#: ../../rst/dev_guide/developing_collections_structure.rst:166
msgid "roles directory"
msgstr "roles ディレクトリー"

#: ../../rst/dev_guide/developing_collections_structure.rst:168
msgid "Collection roles are mostly the same as existing roles, but with a couple of limitations:"
msgstr "コレクションロールは既存ロールとほぼ同じですが、いくつか制限があります。"

#: ../../rst/dev_guide/developing_collections_structure.rst:170
msgid "Role names are now limited to contain only lowercase alphanumeric characters, plus ``_`` and start with an alpha character."
msgstr "ロール名は、小文字の英数字と ``_`` のみを含み、英字で開始するように制限されます。"

#: ../../rst/dev_guide/developing_collections_structure.rst:171
msgid "Roles in a collection cannot contain plugins any more. Plugins must live in the collection ``plugins`` directory tree. Each plugin is accessible to all roles in the collection."
msgstr "コレクション内のロールにはプラグインを含めることができません。プラグインはコレクションの ``plugins`` ディレクトリーツリーで持続する必要があります。各プラグインはコレクション内のすべてのロールからアクセスできます。"

#: ../../rst/dev_guide/developing_collections_structure.rst:173
msgid "The directory name of the role is used as the role name. Therefore, the directory name must comply with the above role name rules. The collection import into Galaxy will fail if a role name does not comply with these rules."
msgstr "ロールのディレクトリー名はロール名として使用されます。そのため、ディレクトリー名は上記のロール名ルールに従う必要があります。Galaxy へのコレクションのインポートは、ロール名がこれらのルールに準拠していないと失敗します。"

#: ../../rst/dev_guide/developing_collections_structure.rst:175
msgid "You can migrate 'traditional roles' into a collection but they must follow the rules above. You may need to rename roles if they don't conform. You will have to move or link any role-based plugins to the collection specific directories."
msgstr "「従来のロール」をコレクションに移行できますが、上記のルールに従う必要があります。遵守していない場合は、ロールの名前を変更しなければならない場合もあります。ロールベースのプラグインをコレクション固有のディレクトリーに移動するか、リンクする必要があります。"

#: ../../rst/dev_guide/developing_collections_structure.rst:179
msgid "For roles imported into Galaxy directly from a GitHub repository, setting the ``role_name`` value in the role's metadata overrides the role name used by Galaxy. For collections, that value is ignored. When importing a collection, Galaxy uses the role directory as the name of the role and ignores the ``role_name`` metadata value."
msgstr "ロールが GitHub リポジトリーから Galaxy に直接インポートされた場合は、ロールのメタデータに ``role_name`` 値を設定すると、Galaxy が使用するロール名が上書きされます。コレクションの場合、この値は無視されます。コレクションをインポートすると、Galaxy はロールディレクトリーをロール名として使用し、``role_name`` メタデータの値を無視します。"

#: ../../rst/dev_guide/developing_collections_structure.rst:182
msgid "playbooks directory"
msgstr "playbooks ディレクトリー"

#: ../../rst/dev_guide/developing_collections_structure.rst:184
msgid "In prior releases, you could reference playbooks in this directory using the full path to the playbook file from the command line. In ansible-core 2.11 and later, you can use the FQCN, ``namespace.collection.playbook`` (with or without extension), to reference the playbooks from the command line or from ``import_playbook``. This will keep the playbook in 'collection context', as if you had added ``collections: [ namespace.collection ]`` to it."
msgstr "以前のリリースでは、コマンドラインからPlaybookファイルのフルパスを使用して、このディレクトリのPlaybookを参照することができました。ansible-core 2.11以降では、FQCNである``namespace.collection.playbook`` （拡張子あり、なし）を使って、コマンドラインまたは``import_playbook`` からPlaybookを参照することができます。これにより、あたかも``collections: [ namespace.collection ]`` を追加したかのように、Playbookが「コレクションコンテキスト」に保たれます。"

#: ../../rst/dev_guide/developing_collections_structure.rst:188
msgid "You can have most of the subdirectories you would expect, such ``files/``, ``vars/`` or  ``templates/`` but no ``roles/`` since those are handled already in the collection."
msgstr "``files/`` 、``vars/`` 、``templates/`` など、期待されるほとんどのサブディレクトリを持つことができますが、``roles/`` はコレクションですでに扱われているため、持つことはできません。"

#: ../../rst/dev_guide/developing_collections_structure.rst:190
msgid "Also, playbooks within a collection follow the same guidelines as any playbooks except for these few adjustments:"
msgstr "また、コレクション内の Playbook は、次のいくつかの調整を除いて、他の Playbook と同じガイドラインに従います。"

#: ../../rst/dev_guide/developing_collections_structure.rst:192
msgid "Directory: It must be in ``/playbooks directory``."
msgstr "ディレクトリー: ``/playbooks directory`` になければなりません。"

#: ../../rst/dev_guide/developing_collections_structure.rst:193
msgid "Hosts: The host should be defined as a variable so the users of a playbook do not mistakenly run the plays against their entire inventory (if the host is set to all). For example - ``hosts: '{{target|default(\"all\")}}'``."
msgstr "ホスト: Playbook のユーザーがインベントリー全体 (ホストがすべてに設定されている場合) に対して誤ってプレイを実行することを防止するため、ホストは変数として定義する必要があります。例: -``hosts: '{{target|default(\"all\")}}'``。"

#: ../../rst/dev_guide/developing_collections_structure.rst:195
msgid "To run the plays, users can now use such commands as ``ansible-playbook --e 'targets=webservers'`` or ``ansible-playbook --limit webservers``. Either way, the collection owner should document their playbooks and how to use them in the ``/docs`` folder or ``README`` file."
msgstr "ユーザーは、``ansible-playbook --e 'targets=webservers'`` や ``ansible-playbook --limit webservers`` などのコマンドを使用してプレイを実行できるようになりました。いずれの方法でも、コレクション所有者は Playbook と、``/docs`` フォルダーまたは ``README`` ファイルでの使用方法を文書化する必要があります。"

#: ../../rst/dev_guide/developing_collections_structure.rst:200
msgid "tests directory"
msgstr "tests ディレクトリー"

#: ../../rst/dev_guide/developing_collections_structure.rst:202
msgid "Ansible Collections are tested much like Ansible itself, by using the `ansible-test` utility which is released as part of Ansible, version 2.9.0 and newer. Because Ansible Collections are tested using the same tooling as Ansible itself, via `ansible-test`, all Ansible developer documentation for testing is applicable for authoring Collections Tests with one key concept to keep in mind."
msgstr "Ansible Collection は、Ansible 自体と同じように、Ansible バージョン 2.9.0 以降に同梱される `ansible-test` ユーティリティーを使用してテストされます。Ansible コレクションは Ansible 自体と同じツールを使用してテストされるため、`ansible-test` を介して、テスト用のすべての Ansible 開発者向けドキュメントは、覚えておくべき 1 つの重要な概念を使用してコレクションテストを作成するために適用できます。"

#: ../../rst/dev_guide/developing_collections_structure.rst:204
msgid "See :ref:`testing_collections` for specific information on how to test collections with ``ansible-test``."
msgstr "``ansible-test`` でコレクションをテストする方法は、「:ref:`testing_collections`」を参照してください。"

#: ../../rst/dev_guide/developing_collections_structure.rst:206
msgid "When reading the :ref:`developing_testing` documentation, there will be content that applies to running Ansible from source code via a git clone, which is typical of an Ansible developer. However, it's not always typical for an Ansible Collection author to be running Ansible from source but instead from a stable release, and to create Collections it is not necessary to run Ansible from source. Therefore, when references of dealing with `ansible-test` binary paths, command completion, or environment variables are presented throughout the :ref:`developing_testing` documentation; keep in mind that it is not needed for Ansible Collection Testing because the act of installing the stable release of Ansible containing `ansible-test` is expected to setup those things for you."
msgstr ":ref:`developing_testing` のドキュメントを読む際、Ansible 開発者の典型的な git clone を使用して、ソースコードから Ansible を実行するコンテンツがあります。ただし、Ansible Collection の作成者がソースから Ansible を実行することは常に一般的ではなく、安定したリリースからではなく、コレクションを作成するには、ソースから Ansible を実行する必要はありません。そのため、`ansible-test` バイナリーパス、コマンド補完、または環境変数については、:ref:`developing_testing` ドキュメントで提示されます。Ansible Collection Testing ではこれが必要ありません。`ansible-test` を含む Ansible の安定したリリースをインストールするには、これらをセットアップすることが予想されるためです。"

#: ../../rst/dev_guide/developing_collections_structure.rst:211
msgid "meta directory and runtime.yml"
msgstr "meta ディレクトリーと runtime.yml"

#: ../../rst/dev_guide/developing_collections_structure.rst:213
msgid "A collection can store some additional metadata in a ``runtime.yml`` file in the collection's ``meta`` directory. The ``runtime.yml`` file supports the top level keys:"
msgstr "コレクションは、コレクションの ``meta`` ディレクトリーの ``runtime.yml`` ファイルに追加のメタデータを保存できます。``runtime.yml`` ファイルは、最上位のキーをサポートします。"

#: ../../rst/dev_guide/developing_collections_structure.rst:215
msgid "*requires_ansible*:"
msgstr "*requires_ansible*:"

#: ../../rst/dev_guide/developing_collections_structure.rst:217
msgid "The version of Ansible Core (ansible-core) required to use the collection. Multiple versions can be separated with a comma."
msgstr "コレクションを使用するために必要な Ansible Core (ansible-core)のバージョン。複数のバージョンはコンマで区切ることができます。"

#: ../../rst/dev_guide/developing_collections_structure.rst:223
msgid "although the version is a `PEP440 Version Specifier <https://www.python.org/dev/peps/pep-0440/#version-specifiers>`_ under the hood, Ansible deviates from PEP440 behavior by truncating prerelease segments from the Ansible version. This means that Ansible 2.11.0b1 is compatible with something that ``requires_ansible: \">=2.11\"``."
msgstr "バージョンは `PEP440 バージョン指定子 <https://www.python.org/dev/peps/pep-0440/#version-specifiers>`_ ですが、内部では、Ansible はプレリリースセグメントを Ansible バージョンから切り捨てることにより、PEP440 の動作から逸脱しています。これは、Ansible2.11.0b1 が ``requires_ansible: \">=2.11\"`` であるものと互換性があることを意味します。"

#: ../../rst/dev_guide/developing_collections_structure.rst:225
msgid "*plugin_routing*:"
msgstr "*plugin_routing*:"

#: ../../rst/dev_guide/developing_collections_structure.rst:227
msgid "Content in a collection that Ansible needs to load from another location or that has been deprecated/removed. The top level keys of ``plugin_routing`` are types of plugins, with individual plugin names as subkeys. To define a new location for a plugin, set the ``redirect`` field to another name. To deprecate a plugin, use the ``deprecation`` field to provide a custom warning message and the removal version or date. If the plugin has been renamed or moved to a new location, the ``redirect`` field should also be provided. If a plugin is being removed entirely, ``tombstone`` can be used for the fatal error message and removal version or date."
msgstr "Ansible が別の場所から読み込む必要があるコレクション内のコンテンツ、もしくは非推奨となったか削除されるコレクションのコンテンツ。``plugin_routing`` の最上位のキーはプラグインのタイプで、個々のプラグイン名をサブキーとして使用します。プラグインの新しい場所を定義するには、``redirect`` フィールドを別の名前に設定します。プラグインを非推奨にするには、``deprecation`` フィールドを使用してカスタム警告メッセージと削除バージョンまたは日付を指定します。プラグインの名前が変更するか新しい場所に移動する場合は、``redirect`` フィールドも入力する必要があります。プラグインが完全に削除される場合、``tombstone`` は致命的なエラーメッセージ、および削除バージョンまたは日付に使用できます。"

#: ../../rst/dev_guide/developing_collections_structure.rst:256
msgid "*import_redirection*"
msgstr "*import_redirection*"

#: ../../rst/dev_guide/developing_collections_structure.rst:258
msgid "A mapping of names for Python import statements and their redirected locations."
msgstr "Python インポートステートメントの名前とそのリダイレクトされた場所のマッピング。"

#: ../../rst/dev_guide/developing_collections_structure.rst:266
msgid "*action_groups*"
msgstr "*action_groups*"

#: ../../rst/dev_guide/developing_collections_structure.rst:268
msgid "A mapping of groups and the list of action plugin and module names they contain. They may also have a special 'metadata' dictionary in the list, which can be used to include actions from other groups."
msgstr "グループと、それに含まれるアクションプラグインおよびモジュール名のリストのマッピングです。また、リストの中に特別な「メタデータ」ディクショナリーを持っている場合もあり、これを使って他のグループのアクションを含めることができます。"

#: ../../rst/dev_guide/developing_collections_structure.rst:286
msgid ":ref:`distributing_collections`"
msgstr ":ref:`distributing_collections`"

#: ../../rst/dev_guide/developing_collections_structure.rst:287
msgid "Learn how to package and publish your collection"
msgstr "コレクションをパッケージ化し、公開する方法を説明します。"

#: ../../rst/dev_guide/developing_collections_testing.rst:5
msgid "Testing collections"
msgstr "コレクションのテスト"

#: ../../rst/dev_guide/developing_collections_testing.rst:7
msgid "Testing your collection ensures that your code works well and integrates well with the rest of the Ansible ecosystem. Your collection should pass the general compile and sanity tests for Ansible code. You should also add unit tests to cover the code in your collection and integration tests to cover the interactions between your collection and ansible-core."
msgstr "コレクションのテストにより、コードが適切に機能し、Ansible エコシステムの他の部分との統合性が向上します。コレクションでは、Ansible コードの一般的なコンパイルおよび健全性テストを渡します。また、コレクションのコードに対応するユニットテストと、コレクションと ansible-core との間の対話に対応する統合テストを追加する必要があります。"

#: ../../rst/dev_guide/developing_collections_testing.rst:14
msgid "Testing tools"
msgstr "テストツール"

#: ../../rst/dev_guide/developing_collections_testing.rst:16
msgid "The main tool for testing collections is ``ansible-test``, Ansible's testing tool described in :ref:`developing_testing` and provided by both the ``ansible`` and ``ansible-core`` packages."
msgstr "コレクションをテストする主なツールは、:ref:`developing_testing` で説明されている Ansible のテストツール ``ansible-test`` です。これは、``ansible`` パッケージと ``ansible-core`` パッケージの両方で提供されます。"

#: ../../rst/dev_guide/developing_collections_testing.rst:18
msgid "You can run several compile and sanity checks, as well as run unit and integration tests for plugins using ``ansible-test``. When you test collections, test against the ansible-core version(s) you are targeting."
msgstr "また、複数のコンパイルチェックと健全性チェックを実行したり、``ansible-test`` を使用してプラグイン用にユニットテストや統合テストを実行できます。コレクションをテストする場合に、使用する ansible-core バージョンに対してテストすることができます。"

#: ../../rst/dev_guide/developing_collections_testing.rst:20
msgid "You must always execute ``ansible-test`` from the root directory of a collection. You can run ``ansible-test`` in Docker containers without installing any special requirements. The Ansible team uses this approach in Azure Pipelines both in the ansible/ansible GitHub repository and in the large community collections such as `community.general <https://github.com/ansible-collections/community.general/>`_ and `community.network <https://github.com/ansible-collections/community.network/>`_. The examples below demonstrate running tests in Docker containers."
msgstr "常に、コレクションのルートディレクトリーから、``ansible-test`` を実行する必要があります。特別な要件をインストールせずに Docker コンテナーの ``ansible-test`` を実行できます。Ansible チームは、ansible/ansible GitHub リポジトリーと、`community.general <https://github.com/ansible-collections/community.general/>`_ や `community.network <https://github.com/ansible-collections/community.network/>`_ ような大規模なコミュニティーコレクションの両方の Azure Pipeline で、このアプローチを使用します。以下の例では、Docker コンテナーでテストの実行方法を示しています。"

#: ../../rst/dev_guide/developing_collections_testing.rst:23
msgid "Compile and sanity tests"
msgstr "コンパイルと健全性テスト"

#: ../../rst/dev_guide/developing_collections_testing.rst:25
msgid "To run all compile and sanity tests:"
msgstr "すべてのコンパイルおよび健全性テストを実行するには、以下を実行します。"

#: ../../rst/dev_guide/developing_collections_testing.rst:31
msgid "See :ref:`testing_compile` and :ref:`testing_sanity` for more information. See the :ref:`full list of sanity tests <all_sanity_tests>` for details on the sanity tests and how to fix identified issues."
msgstr "詳細は、:ref:`testing_compile` および :ref:`testing_sanity` を参照してください。健全性テストの詳細と、特定された問題を修正する方法は、「:ref:`健全性テストの完全リスト <all_sanity_tests>`」を参照してください。"

#: ../../rst/dev_guide/developing_collections_testing.rst:34
msgid "Adding unit tests"
msgstr "ユニットテストの追加"

#: ../../rst/dev_guide/developing_collections_testing.rst:36
msgid "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/main/tests/unit/>`_."
msgstr "ユニットテストを適切な ``tests/unit/plugins/`` ディレクトリーに置く必要があります。たとえば、``tests/unit/plugins/module_utils/foo/test_bar.py`` または ``tests/unit/plugins/module_utils/foo/bar/test_bar.py`` の ``plugins/module_utils/foo/bar.py`` にテストを置きます。たとえば、`unit tests in community.general <https://github.com/ansible-collections/community.general/tree/main/tests/unit/>`_ を参照してください。"

#: ../../rst/dev_guide/developing_collections_testing.rst:38
msgid "To run all unit tests for all supported Python versions:"
msgstr "サポートされるすべての Python バージョンに対して、すべてのユニットテストを実行するには、以下のコマンドを実行します。"

#: ../../rst/dev_guide/developing_collections_testing.rst:44
msgid "To run all unit tests only for a specific Python version:"
msgstr "特定の Python バージョンに対してのみ、ユニットテストをすべて実行するには、以下を実行します。"

#: ../../rst/dev_guide/developing_collections_testing.rst:50
msgid "To run only a specific unit test:"
msgstr "特定のユニットテストのみを実行するには、以下を実行します。"

#: ../../rst/dev_guide/developing_collections_testing.rst:56
msgid "You can specify Python requirements in the ``tests/unit/requirements.txt`` file. See :ref:`testing_units` for more information, especially on fixture files."
msgstr "``tests/unit/requirements.txt`` ファイルで Python 要件を指定できます。詳細 (特にフィクスチャーファイルの詳細) は、「:ref:`testing_units`」を参照してください。"

#: ../../rst/dev_guide/developing_collections_testing.rst:61
msgid "Adding integration tests"
msgstr "統合テストの追加"

#: ../../rst/dev_guide/developing_collections_testing.rst:63
msgid "You must place integration tests in the appropriate ``tests/integration/targets/`` directory. For module integration tests, you can use the module name alone. For example, you would place integration tests for ``plugins/modules/foo.py`` in a directory called ``tests/integration/targets/foo/``. For non-module plugin integration tests, you must add the plugin type to the directory name. For example, you would place integration tests for ``plugins/connections/bar.py`` in a directory called ``tests/integration/targets/connection_bar/``. For lookup plugins, the directory must be called ``lookup_foo``, for inventory plugins, ``inventory_foo``, and so on."
msgstr "統合テストは、適切な ``tests/integration/targets/`` ディレクトリーに置く必要があります。モジュールの統合テストでは、モジュール名だけを使用することができます。たとえば、``plugins/modules/foo.py`` の統合テストを ``tests/integration/targets/foo/`` というディレクトリーに置くことになります。モジュール以外のプラグインの統合テストでは、ディレクトリー名にプラグインタイプを追加する必要があります。たとえば、``plugins/connections/bar.py`` の統合テストは、``tests/integration/targets/connection_bar/`` というディレクトリーに置くことになります。たとえば、ルックアッププラグインの場合、ディレクトリー名は ``lookup_foo`` となり、インベントリプラグインの場合は、``inventory_foo`` となります。"

#: ../../rst/dev_guide/developing_collections_testing.rst:65
msgid "You can write two different kinds of integration tests:"
msgstr "2 種類の統合テストを作成できます。"

#: ../../rst/dev_guide/developing_collections_testing.rst:67
msgid "Ansible role tests run with ``ansible-playbook`` and validate various aspects of the module. They can depend on other integration tests (usually named ``prepare_bar`` or ``setup_bar``, which prepare a service or install a requirement named ``bar`` in order to test module ``foo``) to set-up required resources, such as installing required libraries or setting up server services."
msgstr "Ansible ロールテストは、``ansible-playbook`` で実行され、モジュールのさまざまな側面を検証します。これらのテストは、他の統合テスト (通常 ``prepare_bar`` または ``setup_bar`` と呼ばれ、モジュール ``foo`` をテストするためにサービスを準備したり、``bar`` という要件をインストールしたりする) に依存して、必要なライブラリーのインストールやサーバーサービスの設定など、必要なリソースを設定することができます。"

#: ../../rst/dev_guide/developing_collections_testing.rst:68
msgid "``runme.sh`` tests run directly as scripts. They can set up inventory files, and execute ``ansible-playbook`` or ``ansible-inventory`` with various settings."
msgstr "``runme.sh`` テストは、直接スクリプトとして実行されます。インベントリーファイルを設定し、さまざまな設定で ``ansible-playbook`` または ``ansible-inventory`` を実行できます。"

#: ../../rst/dev_guide/developing_collections_testing.rst:70
msgid "For examples, see the `integration tests in community.general <https://github.com/ansible-collections/community.general/tree/main/tests/integration/targets/>`_. See also :ref:`testing_integration` for more details."
msgstr "例については、`integration tests in community.general <https://github.com/ansible-collections/community.general/tree/main/tests/integration/targets/>`_ を参照してください。詳細は、:ref:`testing_integration` も参照してください。"

#: ../../rst/dev_guide/developing_collections_testing.rst:72
msgid "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 ``fedora35`` image."
msgstr "統合テストは、要件のインストールや、サービスの設定、開始、および停止を行うことができるため、可能な限り、Docker コンテナーや、制限された環境で実行することが推奨されます。デフォルトでは、``ansible-test`` は複数のオペレーティングシステムの Docker イメージをサポートします。すべてのオプションは `list of supported docker images <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_data/completion/docker.txt>`_ を参照してください。クラウドモジュール用などのプラットフォームに依存しない統合テストには、主に ``default`` イメージを使用します。以下の例では、``fedora35`` イメージが使用されています。"

#: ../../rst/dev_guide/developing_collections_testing.rst:74
msgid "To execute all integration tests for a collection:"
msgstr "コレクションに対して統合テストをすべて実行するには、次を実行します。"

#: ../../rst/dev_guide/developing_collections_testing.rst:80
msgid "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."
msgstr "より詳細な出力が必要な場合は、``-v`` ではなく、``-vvv`` でコマンドを実行します。もしくは、``--retry-on-error`` を指定して、失敗したテストを、詳細レベルをあげて自動的に再実行します。"

#: ../../rst/dev_guide/developing_collections_testing.rst:82
msgid "To execute only the integration tests in a specific directory:"
msgstr "特定のディレクトリーで統合テストのみを実行するには、以下を行います。"

#: ../../rst/dev_guide/developing_collections_testing.rst:88
msgid "You can specify multiple target names. Each target name is the name of a directory in ``tests/integration/targets/``."
msgstr "複数のターゲット名を指定できます。ターゲット名は ``tests/integration/targets/`` のディレクトリーの名前になります。"

#: ../../rst/dev_guide/developing_collections_testing.rst:92
msgid ":ref:`developing_testing`"
msgstr ":ref:`developing_testing`"

#: ../../rst/dev_guide/developing_collections_testing.rst:93
msgid "More resources on testing Ansible"
msgstr "Ansible のテストに関するその他のリソース"

#: ../../rst/dev_guide/developing_core.rst:3
msgid "Developing ``ansible-core``"
msgstr "``ansible-core`` の開発"

#: ../../rst/dev_guide/developing_core.rst:5
msgid "Although ``ansible-core`` (the code hosted in the `ansible/ansible repository <https://github.com/ansible/ansible>`_ on GitHub) includes a few plugins that can be swapped out via playbook directives or configuration, much of the code there is not modular.  The documents here give insight into how the parts of ``ansible-core`` work together."
msgstr "``ansible-core`` (GitHub の `ansible/ansible リポジトリー <https://github.com/ansible/ansible>`_ でホストされるコード) には、Playbook ディレクティブまたは設定を介してスワップできるプラグインが含まれていますが、モジュール化されないコードが多くあります。また、``ansible-core`` の一部が連携する方法に関するドキュメントです。"

#: ../../rst/dev_guide/developing_core.rst:15
#: ../../rst/dev_guide/developing_inventory.rst:473
#: ../../rst/dev_guide/developing_plugins.rst:540
msgid ":ref:`developing_api`"
msgstr ":ref:`developing_api`"

#: ../../rst/dev_guide/developing_core.rst:16
#: ../../rst/dev_guide/developing_plugins.rst:541
msgid "Learn about the Python API for task execution"
msgstr "タスク実行用の Python API について"

#: ../../rst/dev_guide/developing_core.rst:18
msgid "Learn about developing plugins"
msgstr "プラグインの開発について"

#: ../../rst/dev_guide/developing_core.rst:21
#: ../../rst/dev_guide/style_guide/index.rst:337
msgid "`irc.libera.chat <https://libera.chat>`_"
msgstr "`irc.libera.chat <https://libera.chat>`_"

#: ../../rst/dev_guide/developing_core.rst:22
msgid "#ansible-devel IRC chat channel"
msgstr "IRC チャットチャンネル (#ansible-devel)"

#: ../../rst/dev_guide/developing_inventory.rst:5
msgid "Developing dynamic inventory"
msgstr "動的インベントリーの開発"

#: ../../rst/dev_guide/developing_inventory.rst:7
msgid "Ansible can pull inventory information from dynamic sources, including cloud sources, by using the supplied :ref:`inventory plugins <inventory_plugins>`. For details about how to pull inventory information, see :ref:`dynamic_inventory`. If the source you want is not currently covered by existing plugins, you can create your own inventory plugin as with any other plugin type."
msgstr "Ansible は、指定された :ref:`インベントリープラグイン <inventory_plugins>` を使用して、クラウドソースを含む動的ソースからインベントリー情報をプルすることができます。インベントリー情報のプル方法の詳細は、「:ref:`dynamic_inventory`」を参照してください。現在、既存のプラグインで対象としていないソースについては、他のプラグインタイプで独自のインベントリープラグインを作成できます。"

#: ../../rst/dev_guide/developing_inventory.rst:9
msgid "In previous versions, you had to create a script or program that could output JSON in the correct format when invoked with the proper arguments. You can still use and write inventory scripts, as we ensured backwards compatibility via the :ref:`script inventory plugin <script_inventory>` and there is no restriction on the programming language used. If you choose to write a script, however, you will need to implement some features yourself such as caching, configuration management, dynamic variable and group composition, and so on. If you use :ref:`inventory plugins <inventory_plugins>` instead, you can use the Ansible codebase and add these common features automatically."
msgstr "以前のバージョンでは、適切な引数で呼び出されたときに正しい形式で JSON を出力できるスクリプトやプログラムを作成する必要がありました。:ref:`script inventory plugin <script_inventory>` を通じて後方互換性を確保しており、使用するプログラミング言語にも制限がないため、インベントリースクリプトを使用したり書いたりすることができます。ただし、スクリプトを書く場合は、キャッシュ、設定管理、動的な変数、グループの構成など、いくつかの機能を自分で実装する必要があります。代わりに :ref:`inventory plugins <inventory_plugins>` を使用すれば、Ansible のコードベースを使用し、これらの共通機能を自動的に追加することができます。"

#: ../../rst/dev_guide/developing_inventory.rst:22
msgid "Inventory sources"
msgstr "インベントリーソース"

#: ../../rst/dev_guide/developing_inventory.rst:24
msgid "Inventory sources are the input strings that inventory plugins work with. An inventory source can be a path to a file or to a script, or it can be raw data that the plugin can interpret."
msgstr "インベントリーソースは、インベントリープラグインが機能する入力文字列です。インベントリーソースはファイルまたはスクリプトへのパスにするか、プラグインが解釈できる生のデータになります。"

#: ../../rst/dev_guide/developing_inventory.rst:27
msgid "The table below shows some examples of inventory plugins and the source types that you can pass to them with ``-i`` on the command line."
msgstr "以下の表は、コマンドラインで ``-i`` を使用して、インベントリープラグインの例と、プラグインに渡すことができるソースタイプを示しています。"

#: ../../rst/dev_guide/developing_inventory.rst:30
msgid "Plugin"
msgstr "プラグイン"

#: ../../rst/dev_guide/developing_inventory.rst:30
msgid "Source"
msgstr "ソース"

#: ../../rst/dev_guide/developing_inventory.rst:32
msgid ":ref:`host list <host_list_inventory>`"
msgstr ":ref:`host list <host_list_inventory>`"

#: ../../rst/dev_guide/developing_inventory.rst:32
msgid "A comma-separated list of hosts"
msgstr "ホストのコンマ区切りリスト"

#: ../../rst/dev_guide/developing_inventory.rst:34
msgid ":ref:`yaml <yaml_inventory>`"
msgstr ":ref:`yaml <yaml_inventory>`"

#: ../../rst/dev_guide/developing_inventory.rst:34
msgid "Path to a YAML format data file"
msgstr "YAML 形式のデータファイルへのパス"

#: ../../rst/dev_guide/developing_inventory.rst:36
msgid ":ref:`constructed <constructed_inventory>`"
msgstr ":ref:`constructed <constructed_inventory>`"

#: ../../rst/dev_guide/developing_inventory.rst:36
#: ../../rst/dev_guide/developing_inventory.rst:40
msgid "Path to a YAML configuration file"
msgstr "YAML 設定ファイルへのパス"

#: ../../rst/dev_guide/developing_inventory.rst:38
msgid ":ref:`ini <ini_inventory>`"
msgstr ":ref:`ini <ini_inventory>`"

#: ../../rst/dev_guide/developing_inventory.rst:38
msgid "Path to an INI formatted data file"
msgstr "INI 形式のデータファイルへのパス"

#: ../../rst/dev_guide/developing_inventory.rst:40
msgid ":ref:`virtualbox <virtualbox_inventory>`"
msgstr ":ref:`virtualbox <virtualbox_inventory>`"

#: ../../rst/dev_guide/developing_inventory.rst:42
msgid ":ref:`script plugin <script_inventory>`"
msgstr ":ref:`script plugin <script_inventory>`"

#: ../../rst/dev_guide/developing_inventory.rst:42
msgid "Path to an executable that outputs JSON"
msgstr "JSON を出力する実行可能ファイルへのパス"

#: ../../rst/dev_guide/developing_inventory.rst:49
#: ../../rst/dev_guide/developing_plugins.rst:334
msgid "Inventory plugins"
msgstr "inventory プラグイン"

#: ../../rst/dev_guide/developing_inventory.rst:51
msgid "Like most plugin types (except modules), inventory plugins must be developed in Python. They execute on the controller and should therefore adhere to the :ref:`control_node_requirements`."
msgstr "ほとんどのプラグインタイプ (モジュールを除く) と同様に、それらは Python で開発されなければなりません。コントローラー上で実行するため、「:ref:`control_node_requirements`」と同じ要件に一致させなければなりません。"

#: ../../rst/dev_guide/developing_inventory.rst:53
msgid "Most of the documentation in :ref:`developing_plugins` also applies here. You should read that document first for a general understanding and then come back to this document for specifics on inventory plugins."
msgstr ":ref:`developing_plugins` に関するドキュメントの多くはここでも適用されています。一般的な理解のために最初にこのドキュメントを読んでから、本ガイドで inventory プラグインの詳細を参照してください。"

#: ../../rst/dev_guide/developing_inventory.rst:55
msgid "Normally, inventory plugins are executed at the start of a run, and before the playbooks, plays, or roles are loaded. However, you can use the ``meta: refresh_inventory`` task to clear the current inventory and execute the inventory plugins again, and this task will generate a new inventory."
msgstr "通常、インベントリープラグインは実行の開始時、および Playbook、プレイ、またはロールが読み込まれる前に実行します。ただし、``meta: refresh_inventory`` タスクを使用して現在のインベントリーを消去してインベントリープラグインを再実行することもできます。また、このタスクは新しいインベントリーを生成します。"

#: ../../rst/dev_guide/developing_inventory.rst:58
msgid "If you use the persistent cache, inventory plugins can also use the configured cache plugin to store and retrieve data. Caching inventory avoids making repeated and costly external calls."
msgstr "永続キャッシュを使用する場合、inventory プラグインは設定済みの cache プラグインを使用してデータを保存および取得し、コストがかかり、繰り返しかかる外部呼び出しを回避することもできます。"

#: ../../rst/dev_guide/developing_inventory.rst:63
msgid "Developing an inventory plugin"
msgstr "inventory プラグインの開発"

#: ../../rst/dev_guide/developing_inventory.rst:65
msgid "The first thing you want to do is use the base class:"
msgstr "最初に行うのは、ベースクラスを使用することです。"

#: ../../rst/dev_guide/developing_inventory.rst:75
msgid "If the inventory plugin is in a collection, the NAME should be in the 'namespace.collection_name.myplugin' format. The base class has a couple of methods that each plugin should implement and a few helpers for parsing the inventory source and updating the inventory."
msgstr "inventory プラグインがコレクションにある場合、NAME は「namespace.collection_name.myplugin」形式である必要があります。このベースクラスは、各プラグインが実装する必要のあるいくつかのメソッドと、インベントリーソースを解析してインベントリーを更新するためのヘルパーがいくつかあります。"

#: ../../rst/dev_guide/developing_inventory.rst:77
msgid "After you have the basic plugin working, you can incorporate other features by adding more base classes:"
msgstr "基本的なプラグインが動作するようになったら、より多くの基本クラスを追加することで他の機能を組み込むことができます。"

#: ../../rst/dev_guide/developing_inventory.rst:87
msgid "For the bulk of the work in a plugin, we mostly want to deal with 2 methods ``verify_file`` and ``parse``."
msgstr "プラグインでの作業の大部分では、主に 2 つのメソッド (``verify_file`` と ``parse``) を扱います。"

#: ../../rst/dev_guide/developing_inventory.rst:92
msgid "verify_file method"
msgstr "verify_file メソッド"

#: ../../rst/dev_guide/developing_inventory.rst:94
msgid "Ansible uses this method to quickly determine if the inventory source is usable by the plugin. The determination does not need to be 100% accurate, as there might be an overlap in what plugins can handle and by default Ansible will try the enabled plugins as per their sequence."
msgstr "Ansible はこのメソッドを使用して、インベントリソースがプラグインで使用可能かどうかを迅速に判断します。この判定は 100％ 正確である必要はありません。なぜなら、プラグインが処理できる内容には重複があり、デフォルトでは Ansible は有効なプラグインを順番に試していくからです。"

#: ../../rst/dev_guide/developing_inventory.rst:107
msgid "In the above example, from the :ref:`virtualbox inventory plugin <virtualbox_inventory>`, we screen for specific file name patterns to avoid attempting to consume any valid YAML file. You can add any type of condition here, but the most common one is 'extension matching'. If you implement extension matching for YAML configuration files, the path suffix <plugin_name>.<yml|yaml> should be accepted. All valid extensions should be documented in the plugin description."
msgstr "上記の例では、:ref:`virtualbox inventory プラグイン <virtualbox_inventory>` からは、有効な YAML ファイルの使用を試みないように、特定のファイル名パターンを切り分けます。ここに任意のタイプの条件を追加できますが、最も一般的なものは「拡張子の一致」です。YAML 設定ファイルに一致する拡張子を実装する場合は、パスサフィックス <plugin_name>.<yml|yaml> が許可される必要があります。有効なすべての拡張機能は、プラグインの説明に記載されています。"

#: ../../rst/dev_guide/developing_inventory.rst:109
msgid "The following is another example that does not use a 'file' but the inventory source string itself, from the :ref:`host list <host_list_inventory>` plugin:"
msgstr "以下は、「ファイル」を使用せず、:ref:`host list <host_list_inventory>` プラグインからインベントリソース文字列自体を使用する別の例です。"

#: ../../rst/dev_guide/developing_inventory.rst:124
msgid "This method is just to expedite the inventory process and avoid unnecessary parsing of sources that are easy to filter out before causing a parse error."
msgstr "この方法は、inventory プロセスを迅速化し、解析エラーの原因になる前に簡単に除外できるソースの不要な解析を回避するためのものです。"

#: ../../rst/dev_guide/developing_inventory.rst:129
msgid "parse method"
msgstr "解析メソッド"

#: ../../rst/dev_guide/developing_inventory.rst:131
msgid "This method does the bulk of the work in the plugin. It takes the following parameters:"
msgstr "この方法は、プラグインの作業の大部分を行います。このメソッドは、以下のパラメーターを取ります。"

#: ../../rst/dev_guide/developing_inventory.rst:134
msgid "inventory: inventory object with existing data and the methods to add hosts/groups/variables to inventory"
msgstr "inventory: 既存のデータと、ホスト/グループ/変数をインベントリーに追加するメソッドがある inventory オブジェクト。"

#: ../../rst/dev_guide/developing_inventory.rst:135
msgid "loader: Ansible's DataLoader. The DataLoader can read files, auto load JSON/YAML and decrypt vaulted data, and cache read files."
msgstr "loader: Ansible の DataLoader です。DataLoader は、ファイルの読み取り、JSON/YAML の自動読み込み、vault を使用したデータの復号化、および読み取りファイルのキャッシュを行うことができます。"

#: ../../rst/dev_guide/developing_inventory.rst:136
msgid "path: string with inventory source (this is usually a path, but is not required)"
msgstr "path: インベントリーソースを持つ文字列 (通常、これはパスですが、必須ではありません)。"

#: ../../rst/dev_guide/developing_inventory.rst:137
msgid "cache: indicates whether the plugin should use or avoid caches (cache plugin and/or loader)"
msgstr "cache: プラグインがキャッシュを使用するかどうかを示します (キャッシュプラグインまたはローダー、もしくはその両方)。"

#: ../../rst/dev_guide/developing_inventory.rst:140
msgid "The base class does some minimal assignment for reuse in other methods."
msgstr "ベースクラスは他のメソッドで再利用するための割り当てを最小限に抑えます。"

#: ../../rst/dev_guide/developing_inventory.rst:150
msgid "It is up to the plugin now to parse the provided inventory source and translate it into Ansible inventory. To facilitate this, the example below uses a few helper functions:"
msgstr "提供されたインベントリーソースを解析し、それを Ansible インベントリーに変換するのは、プラグイン次第です。これを容易にするために、以下の例ではいくつかのヘルパー関数を使用しています。"

#: ../../rst/dev_guide/developing_inventory.rst:187
msgid "The specifics will vary depending on API and structure returned. Remember that if you get an inventory source error or any other issue, you should ``raise AnsibleParserError`` to let Ansible know that the source was invalid or the process failed."
msgstr "この状況は、API および構造の戻り値によって異なります。インベントリーソースエラーや他の問題を取得する場合は、``AnsibleParserError を発生`` させ、ソースが無効であるか、プロセスが失敗したことを Ansible に通知する必要があります。"

#: ../../rst/dev_guide/developing_inventory.rst:189
msgid "For examples on how to implement an inventory plugin, see the source code here: `lib/ansible/plugins/inventory <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/inventory>`_."
msgstr "インベントリープラグインの実装方法の例は、ソースコード (`lib/ansible/plugins/inventory <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/inventory>`_) を参照してください。"

#: ../../rst/dev_guide/developing_inventory.rst:195
msgid "inventory cache"
msgstr "インベントリーキャッシュ"

#: ../../rst/dev_guide/developing_inventory.rst:197
msgid "To cache the inventory, extend the inventory plugin documentation with the inventory_cache documentation fragment and use the Cacheable base class."
msgstr "インベントリーをキャッシュするには、インベントリープラグインのドキュメントを inventory_cache ドキュメントフラグメントで拡張し、cacheable 基本クラスを使用します。"

#: ../../rst/dev_guide/developing_inventory.rst:210
msgid "Next, load the cache plugin specified by the user to read from and update the cache. If your inventory plugin uses YAML-based configuration files and the ``_read_config_data`` method, the cache plugin is loaded within that method. If your inventory plugin does not use ``_read_config_data``, you must load the cache explicitly with ``load_cache_plugin``."
msgstr "次に、ユーザーが指定したキャッシュプラグインを読み込み、キャッシュの読み取りと更新を行います。インベントリープラグインが YAML ベースの構成ファイルを使用していて、``_read_config_data`` メソッドの場合、キャッシュプラグインはそのメソッド内に読み込まれます。インベントリープラグインが ``_read_config_data`` を使用しない場合は、``load_cache_plugin`` を使用してキャッシュを明示的に読み込む必要があります。"

#: ../../rst/dev_guide/developing_inventory.rst:221
msgid "Before using the cache plugin, you must retrieve a unique cache key by using the ``get_cache_key`` method. This task needs to be done by all inventory modules using the cache, so that you don't use/overwrite other parts of the cache."
msgstr "キャッシュプラグインを使用する前に、``get_cache_key`` メソッドを使用して一意のキャッシュキーを取得する必要があります。このタスクは、キャッシュを使用するすべてのインベントリーモジュールで実行する必要があります。これにより、キャッシュの他の部分を使用/上書きしないようになります。"

#: ../../rst/dev_guide/developing_inventory.rst:231
msgid "Now that you've enabled caching, loaded the correct plugin, and retrieved a unique cache key, you can set up the flow of data between the cache and your inventory using the ``cache`` parameter of the ``parse`` method. This value comes from the inventory manager and indicates whether the inventory is being refreshed (such as via ``--flush-cache`` or the meta task ``refresh_inventory``). Although the cache shouldn't be used to populate the inventory when being refreshed, the cache should be updated with the new inventory if the user has enabled caching. You can use ``self._cache`` like a dictionary. The following pattern allows refreshing the inventory to work in conjunction with caching."
msgstr "これでキャッシュを有効にし、正しいプラグインを読み込み、一意のキャッシュキーを取得し、``parse`` メソッドの ``cache`` パラメーターを使用して、キャッシュとインベントリーの間でデータのフローを設定できるようになりました。この値は、インベントリーマネージャーから取得され、インベントリーを更新するか (例: ``--flush-cache``、メタタスク ``refresh_inventory`` など) を示します。キャッシュは、更新時にインベントリーを入力するために使用しますが、キャッシュを有効にした場合は、キャッシュを新しいインベントリーで更新する必要があります。ディクショナリーのような ``self._cache`` を使用できます。以下のパターンを使用すると、インベントリーをキャッシュとともに動作させることができます。"

#: ../../rst/dev_guide/developing_inventory.rst:266
msgid "After the ``parse`` method is complete, the contents of ``self._cache`` is used to set the cache plugin if the contents of the cache have changed."
msgstr "``parse`` メソッドが完了すると、``self._cache`` の内容は、キャッシュの内容が変更された場合にキャッシュプラグインを設定するために使用されます。"

#: ../../rst/dev_guide/developing_inventory.rst:271
msgid "You have three other cache methods available:"
msgstr "利用可能な 3 つのキャッシュメソッド:"

#: ../../rst/dev_guide/developing_inventory.rst:269
msgid "``set_cache_plugin`` forces the cache plugin to be set with the contents of ``self._cache``, before the ``parse`` method completes"
msgstr "``set_cache_plugin`` は、``parse`` メソッドの完了前に、キャッシュプラグインを ``self._cache`` の内容で強制的に設定します。"

#: ../../rst/dev_guide/developing_inventory.rst:270
msgid "``update_cache_if_changed`` sets the cache plugin only if ``self._cache`` has been modified, before the ``parse`` method completes"
msgstr "``update_cache_if_changed`` は、``parse`` メソッドが完了する前に ``self._cache`` が変更された場合のみキャッシュプラグインを設定します。"

#: ../../rst/dev_guide/developing_inventory.rst:271
msgid "``clear_cache`` flushes the cache, ultimately by calling the cache plugin's ``flush()`` method, whose implementation is dependent upon the particular cache plugin in use. Note that if the user is using the same cache backend for facts and inventory, both will get flushed. To avoid this, the user can specify a distinct cache backend in their inventory plugin configuration."
msgstr "``clear_cache`` キャッシュをフラッシュし、キャッシュプラグインの ``flush()`` メソッドを呼び出すことで、これらの実装は使用中の特定のキャッシュプラグインに依存します。ファクトとインベントリーで同じキャッシュバックエンドを使用している場合は、両方のキャッシュバックエンドをフラッシュします。これを回避するために、インベントリープラグイン設定で個別のキャッシュバックエンドを指定できます。"

#: ../../rst/dev_guide/developing_inventory.rst:274
msgid "constructed features"
msgstr "constructed 機能"

#: ../../rst/dev_guide/developing_inventory.rst:276
msgid "Inventory plugins can create host variables and groups from Jinja2 expressions and variables by using features from the ``constructed`` inventory plugin. To do this, use the ``Constructable`` base class and extend the inventory plugin's documentation with the ``constructed`` documentation fragment."
msgstr "インベントリープラグインは、``constructed`` インベントリープラグインの機能を使用して、Jinja2 式および変数からホスト変数およびグループを作成できます。これを行うには、``Constructable`` ベースクラスを使用し、``constructed`` ドキュメントフラグメントでドキュメントを拡張することができます。"

#: ../../rst/dev_guide/developing_inventory.rst:289
msgid "The three main options from the ``constructed`` documentation fragment are ``compose``, ``keyed_groups``, and ``groups``. See the ``constructed`` inventory plugin for examples on using these. ``compose`` is a dictionary of variable names and Jinja2 expressions. Once a host is added to inventory and any initial variables have been set, call the method ``_set_composite_vars`` to add composed host variables. If this is done before adding ``keyed_groups`` and ``groups``, the group generation will be able to use the composed variables."
msgstr "``constructed`` ドキュメントフラグの 3 つの主要なオプションは、``compose``、``keyed_groups``、および ``groups`` です。これらの使用例は、``constructed`` インベントリープラグインを参照してください。``compose`` は、変数名および Jinja2 式のディクショナリーです。ホストがインベントリーに追加され、初期変数が設定されると、``_set_composite_vars`` メソッドを呼び出して構成されたホスト変数を追加します。``keyed_groups`` および ``groups`` を追加する前にこれを行うと、グループの生成は構成された変数を使用できます。"

#: ../../rst/dev_guide/developing_inventory.rst:310
msgid "By default, group names created with ``_add_host_to_composed_groups()`` and ``_add_host_to_keyed_groups()`` are valid Python identifiers. Invalid characters are replaced with an underscore ``_``. A plugin can change the sanitization used for the constructed features by setting ``self._sanitize_group_name`` to a new function. The core engine also does sanitization, so if the custom function is less strict it should be used in conjunction with the configuration setting ``TRANSFORM_INVALID_GROUP_CHARS``."
msgstr "デフォルトでは、``_add_host_to_composed_groups()`` および ``_add_host_to_keyed_groups()`` で作成されたグループ名は有効な Python 識別子です。無効な文字はアンダースコア ``_`` に置き換えられます。プラグインは、``self._sanitize_group_name`` を新しい機能に設定することで、constructed 機能に使用されるサニタイゼーションを変更できます。コアエンジンもサニタイゼーションを実行するため、カスタム機能がそれほど厳密でない場合は、構成設定 ``TRANSFORM_INVALID_GROUP_CHARS`` と組み合わせて使用する必要があります。"

#: ../../rst/dev_guide/developing_inventory.rst:332
msgid "Common format for inventory sources"
msgstr "インベントリーソースの共通形式"

#: ../../rst/dev_guide/developing_inventory.rst:334
msgid "To simplify development, most plugins use a standard YAML-based configuration file as the inventory source. The file has only one required field ``plugin``, which should contain the name of the plugin that is expected to consume the file. Depending on other common features used, you might need other fields, and you can add custom options in each plugin as required. For example, if you use the integrated caching, ``cache_plugin``, ``cache_timeout`` and other cache-related fields could be present."
msgstr "開発を簡単にするために、ほとんどのプラグインはインベントリーソースとして標準的な YAML ベースの設定ファイルを使用しています。このファイルには、必須フィールドが 1 つしかありません (``plugin``)。このフィールドには、このファイルを使用することが期待されるプラグインの名前を入れる必要があります。使用する他の共通機能によっては、他のフィールドが必要になる場合があり、必要に応じて各プラグインにカスタムオプションを追加することができます。たとえば、統合キャッシングを使用する場合は、``cache_plugin``、``cache_timeout`` などのキャッシュ関連のフィールドが存在する可能性があります。"

#: ../../rst/dev_guide/developing_inventory.rst:341
msgid "The 'auto' plugin"
msgstr "「auto」プラグイン"

#: ../../rst/dev_guide/developing_inventory.rst:343
msgid "From Ansible 2.5 onwards, we include the :ref:`auto inventory plugin <auto_inventory>` and enable it by default. If the ``plugin`` field in your standard configuration file matches the name of your inventory plugin, the ``auto`` inventory plugin will load your plugin. The 'auto' plugin makes it easier to use your plugin without having to update configurations."
msgstr "Ansible 2.5 以降では、:ref:`auto inventory plugin <auto_inventory>` を追加し、これをデフォルトで有効化します。標準設定ファイルの ``plugin`` フィールドがインベントリープラグインの名前と一致する場合、``auto`` インベントリープラグインはプラグインを読み込みます。「auto」プラグインは、設定を更新せずにプラグインを簡単に使用できます。"

#: ../../rst/dev_guide/developing_inventory.rst:350
msgid "Inventory scripts"
msgstr "インベントリースクリプト"

#: ../../rst/dev_guide/developing_inventory.rst:352
msgid "Even though we now have inventory plugins, we still support inventory scripts, not only for backwards compatibility but also to allow users to use other programming languages."
msgstr "inventory プラグインはそのままですが、後方互換性だけでなく、ユーザーが他のプログラミング言語を使用できるように、引き続きインベントリースクリプトをサポートします。"

#: ../../rst/dev_guide/developing_inventory.rst:358
msgid "Inventory script conventions"
msgstr "インベントリースクリプトの規則"

#: ../../rst/dev_guide/developing_inventory.rst:360
msgid "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."
msgstr "インベントリースクリプトでは、引数 ``--list`` および ``--host <hostname>`` を使用する必要があります。他の引数は設定できますが、Ansible はそれらを使用しません。このような引数は、スクリプトを直接実行するのに役立つ場合があります。"

#: ../../rst/dev_guide/developing_inventory.rst:363
msgid "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:"
msgstr "スクリプトが単一の引数 ``--list`` で呼び出されると、スクリプトは、標準出力に、管理するすべてのグループが含まれる JSON オブジェクトを出力する必要があります。各グループの値は、各ホスト、子グループ、および潜在的なグループ変数の一覧を含むオブジェクト、または簡単にホストの一覧にする必要があります。"

#: ../../rst/dev_guide/developing_inventory.rst:386
msgid "If any of the elements of a group are empty, they may be omitted from the output."
msgstr "グループのいずれかの要素が空の場合は、出力から省略される可能性があります。"

#: ../../rst/dev_guide/developing_inventory.rst:388
msgid "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:"
msgstr "引数 ``--host <hostname>`` で呼び出される場合 (<hostname> は上記のホスト) で呼び出されると、スクリプトは、空か、変数を含む JSON オブジェクトを出力して、テンプレートと Playbook で利用可能にする必要があります。以下に例を示します。"

#: ../../rst/dev_guide/developing_inventory.rst:397
msgid "Printing variables is optional. If the script does not print variables, it should print an empty JSON object."
msgstr "変数の出力は任意です。スクリプトが変数を出力しない場合は、空の JSON オブジェクトを出力する必要があります。"

#: ../../rst/dev_guide/developing_inventory.rst:402
msgid "Tuning the external inventory script"
msgstr "外部インベントリースクリプトのチューニング"

#: ../../rst/dev_guide/developing_inventory.rst:406
msgid "The stock inventory script system mentioned above works for all versions of Ansible, but calling ``--host`` for every host can be rather inefficient, especially if it involves API calls to a remote subsystem."
msgstr "上記のストックのインベントリースクリプトシステムは、すべてのバージョンの Ansible に対して動作しますが、特にリモートサブシステムへの API 呼び出しが必要になる場合は、すべてのホストに対して ``--host`` を呼び出すこともできます。"

#: ../../rst/dev_guide/developing_inventory.rst:408
msgid "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."
msgstr "これを回避するには、インベントリースクリプトが「_meta」という最上位の要素を返す場合には、単一スクリプトの実行ですべてのホスト変数を返すことができます。このメタ要素に「hostvars」の値が含まれていると、インベントリースクリプトは各ホストに対して ``--host`` で呼び出されません。この動作は、多数のホストのパフォーマンスを大幅に向上します。"

#: ../../rst/dev_guide/developing_inventory.rst:410
msgid "The data to be added to the top-level JSON object looks like this:"
msgstr "レベルの JSON オブジェクトに追加するデータは次のようになります。"

#: ../../rst/dev_guide/developing_inventory.rst:431
msgid "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:"
msgstr "Ansible が ``--host`` でインベントリーを呼び出すのを防ぐために ``_meta`` を使用する要件を満たすには、少なくとも空の ``hostvars`` オブジェクトで ``_meta`` を埋めなければなりません。以下に例を示します。"

#: ../../rst/dev_guide/developing_inventory.rst:449
msgid "If you intend to replace an existing static inventory file with an inventory script, it must return a JSON object which contains an 'all' group that includes every host in the inventory as a member and every group in the inventory as a child. It should also include an 'ungrouped' group which contains all hosts which are not members of any other group. A skeleton example of this JSON object is:"
msgstr "既存の静的インベントリーファイルをインベントリースクリプトに置き換える場合は、インベントリー内のすべてのホストをメンバーとして、インベントリー内のすべてのグループを子として含む「すべて」のグループを含む JSON オブジェクトを返す必要があります。また、他のグループのメンバーではないすべてのホストを含む「グループ化されていない」グループも含める必要があります。この JSON オブジェクトのスケルトンの例は次のとおりです。"

#: ../../rst/dev_guide/developing_inventory.rst:469
msgid "An easy way to see how this should look is using :ref:`ansible-inventory`, which also supports ``--list`` and ``--host`` parameters like an inventory script would."
msgstr "これがどのように見えるかを確認する簡単な方法は、:ref:`ansible-inventory` を使用することです。これにより、インベントリースクリプトのように ``--list`` パラメーターおよび ``--host`` パラメーターがサポートされます。"

#: ../../rst/dev_guide/developing_inventory.rst:474
msgid "Python API to Playbooks and Ad Hoc Task Execution"
msgstr "Playbook およびアドホックタスク実行のための Python API"

#: ../../rst/dev_guide/developing_inventory.rst:476
msgid "Get started with developing a module"
msgstr "モジュールの開発を始める"

#: ../../rst/dev_guide/developing_inventory.rst:479
msgid "`AWX <https://github.com/ansible/awx>`_"
msgstr "`AWX <https://github.com/ansible/awx>`_"

#: ../../rst/dev_guide/developing_inventory.rst:480
msgid "REST API endpoint and GUI for Ansible, syncs with dynamic inventory"
msgstr "Ansible の REST API エンドポイントおよび GUI (動的インベントリーと同期)"

#: ../../rst/dev_guide/developing_locally.rst:6
msgid "Adding modules and plugins locally"
msgstr "モジュールおよびプラグインをローカルで追加"

#: ../../rst/dev_guide/developing_locally.rst:8
msgid "You can extend Ansible by adding custom modules or plugins. You can create them from scratch or copy existing ones for local use. You can store a local module or plugin on your Ansible control node and share it with your team or organization. You can also share plugins and modules by including them in a collection, then publishing the collection on Ansible Galaxy."
msgstr "カスタムモジュールやプラグインを追加してAnsibleを拡張することができます。カスタムモジュールやプラグインは、ゼロから作成することも、既存のものをコピーしてローカルで使用することもできます。ローカルのモジュールやプラグインは、Ansibleコントロールノードに保存して、チームや組織で共有することができます。また、プラグインやモジュールをコレクションに含め、そのコレクションをAnsible Galaxyで公開することでも共有できます。"

#: ../../rst/dev_guide/developing_locally.rst:10
msgid "If you are using a local module or plugin but Ansible cannot find it, this page is all you need."
msgstr "ローカルモジュールやプラグインを使用しているが、Ansibleがそれを見つけられない場合、このページですべて解決します。"

#: ../../rst/dev_guide/developing_locally.rst:12
msgid "If you want to create a plugin or a module, see :ref:`developing_plugins`, :ref:`developing_modules_general` and :ref:`developing_collections`."
msgstr "プラグインやモジュールを作成したい場合は、:ref:`developing_plugins`、:ref:`developing_modules_general`、:ref:`developing_collections` を参照してください。"

#: ../../rst/dev_guide/developing_locally.rst:14
msgid "Extending Ansible with local modules and plugins offers shortcuts such as:"
msgstr "ローカルのモジュールおよびプラグインで Ansible を拡張すると、以下のようなショートカットが利用できるようになります。"

#: ../../rst/dev_guide/developing_locally.rst:16
msgid "You can copy other people's modules and plugins."
msgstr "他のユーザーのモジュールおよびプラグインをコピーできます。"

#: ../../rst/dev_guide/developing_locally.rst:17
msgid "When writing a new module, you can choose any programming language you like."
msgstr "新しいモジュールを作成する場合は、任意のプログラミング言語を選択できます。"

#: ../../rst/dev_guide/developing_locally.rst:18
msgid "You do not have to clone any repositories."
msgstr "リポジトリーのクローンを作成する必要はありません。"

#: ../../rst/dev_guide/developing_locally.rst:19
msgid "You do not have to open a pull request."
msgstr "プル要求を開く必要はありません。"

#: ../../rst/dev_guide/developing_locally.rst:20
msgid "You do not have to add tests (though we recommend that you do!)."
msgstr "テストを追加する必要はありません (ただし、この操作を推奨しています)。"

#: ../../rst/dev_guide/developing_locally.rst:28
msgid "Modules and plugins: what is the difference?"
msgstr "モジュールおよびプラグイン: 相違点"

#: ../../rst/dev_guide/developing_locally.rst:29
msgid "If you are looking to add functionality to Ansible, you might wonder whether you need a module or a plugin. Here is a quick overview to help you understand what you need:"
msgstr "Ansible に機能を追加する場合は、モジュールまたはプラグインのどちらが必要か疑問に思う場合があります。以下に、必要なものを理解するのに役立つ概要を示します。"

#: ../../rst/dev_guide/developing_locally.rst:31
msgid "Modules are reusable, standalone scripts that can be used by the Ansible API, the :command:`ansible` command, or the :command:`ansible-playbook` command. Modules provide a defined interface. Each module accepts arguments and returns information to Ansible by printing a JSON string to stdout before exiting. Modules execute on the target system (usually that means on a remote system) in separate processes. Modules are technically plugins, but for historical reasons we do not usually talk about \"module plugins\"."
msgstr "モジュールは、Ansible API、:command:`ansible` コマンド、または :command:`ansible-playbook` コマンドで使用できる再利用可能なスタンドアロンスクリプトです。モジュールは、定義されたインターフェースを提供します。各モジュールは引数を受け入れ、終了する前に JSON 文字列を stdout に出力して Ansible に情報を返します。モジュールは、別のプロセスでターゲットシステム (通常はリモートシステム上) で実行されます。モジュールは技術的にはプラグインですが、過去の経緯から、通常「モジュールプラグイン」とは呼びません。"

#: ../../rst/dev_guide/developing_locally.rst:32
msgid ":ref:`Plugins <working_with_plugins>` extend Ansible's core functionality and execute on the control node within the ``/usr/bin/ansible`` process. Plugins offer options and extensions for the core features of Ansible - transforming data, logging output, connecting to inventory, and more."
msgstr ":ref:`Plugins <working_with_plugins>` は、Ansible のコア機能を拡張し、``/usr/bin/ansible`` プロセス内のコントロールノードで実行します。プラグインは、Ansible のコア機能のオプションおよび拡張機能 (データの変換、ログ出力、インベントリーへの接続など) を提供します。"

#: ../../rst/dev_guide/developing_locally.rst:37
msgid "Adding modules and plugins in collections"
msgstr "コレクションでのモジュールとプラグインの追加"

#: ../../rst/dev_guide/developing_locally.rst:39
msgid "You can add modules and plugins by :ref:`creating a collection <developing_collections>`. With a collection, you can use custom modules and plugins in any playbook or role. You can share your collection easily at any time through Ansible Galaxy."
msgstr "モジュールやプラグインは、:ref:`creating a collection <developing_collections>` で追加できます。コレクションがあれば、任意のPlaybookやロールでカスタムモジュールやプラグインを使用することができます。コレクションは、Ansible Galaxyを使っていつでも簡単に共有することができます。"

#: ../../rst/dev_guide/developing_locally.rst:41
msgid "The rest of this page describes other methods of using local, standalone modules or plugins."
msgstr "このページの残りの部分では、ローカルのスタンドアロンのモジュールやプラグインを使用する他の方法について説明します。"

#: ../../rst/dev_guide/developing_locally.rst:46
msgid "Adding a module outside of a collection"
msgstr "コレクション外のモジュールの追加"

#: ../../rst/dev_guide/developing_locally.rst:48
msgid "You can configure Ansible to load standalone local modules in a specified location or locations and make them available to all playbooks and roles. Alternatively, you can make a non-collection local module available only to specific playbooks or roles."
msgstr "指定した場所のスタンドアロンのローカルモジュールを読みこむようにAnsibleを設定し、すべてのPlaybookやロールで利用できるようにすることができます。また、コレクションではないローカルモジュールを特定のPlaybookやロールでのみ利用できるようにすることもできます。"

#: ../../rst/dev_guide/developing_locally.rst:51
msgid "Adding standalone local modules for all playbooks and roles"
msgstr "すべてのPlaybookとロールに対するスタンドアロンのローカルモジュールの追加"

#: ../../rst/dev_guide/developing_locally.rst:53
msgid "To load standalone local modules automatically and make them available to all playbooks and roles, use the :ref:`DEFAULT_MODULE_PATH` configuration setting or the ``ANSIBLE_LIBRARY`` environment variable. The configuration setting and environment variable take a colon-separated list, similar to ``$PATH``. You have two options:"
msgstr "スタンドアロンのローカルモジュールを自動的に読み込み、すべてのPlaybookとロールで利用できるようにするには、:ref:`DEFAULT_MODULE_PATH` の構成設定または``ANSIBLE_LIBRARY`` の環境変数を使用します。``$PATH`` と同様に、構成設定や環境変数はコロンで区切られたリストを受け取ります。2つのオプションがあります。"

#: ../../rst/dev_guide/developing_locally.rst:55
msgid "Add your standalone local module to one of the default configured locations. See the :ref:`DEFAULT_MODULE_PATH` configuration setting for details. Default locations may change without notice."
msgstr "スタンドアロンのローカルモジュールを、デフォルトで設定されている場所の一つに追加します。詳しくは、:ref:`DEFAULT_MODULE_PATH` の構成設定をご覧ください。デフォルトのロケーションは予告なく変更されることがあります。"

#: ../../rst/dev_guide/developing_locally.rst:58
msgid "Add the location of your standalone local module to an environment variable or configuration:"
msgstr "スタンドアロンのローカルモジュールの場所を、環境変数や設定に追加します。"

#: ../../rst/dev_guide/developing_locally.rst:57
msgid "the ``ANSIBLE_LIBRARY`` environment variable"
msgstr "``ANSIBLE_LIBRARY`` 環境変数"

#: ../../rst/dev_guide/developing_locally.rst:58
msgid "the :ref:`DEFAULT_MODULE_PATH` configuration setting"
msgstr ":ref:`DEFAULT_MODULE_PATH` 構成設定"

#: ../../rst/dev_guide/developing_locally.rst:60
msgid "To view your current configuration settings for modules:"
msgstr "モジュールの現在の構成設定を表示するには："

#: ../../rst/dev_guide/developing_locally.rst:66
msgid "After you save your module file in one of these locations, Ansible loads it and you can use it in any local task, playbook, or role."
msgstr "モジュールファイルをこのいずれかの場所に保存すると、Ansible はそのファイルを読み込み、ローカルのタスク、Playbook、またはロールで使用できます。"

#: ../../rst/dev_guide/developing_locally.rst:68
msgid "To confirm that ``my_local_module`` is available:"
msgstr "``my_local_module`` が利用可能であることを確認するには："

#: ../../rst/dev_guide/developing_locally.rst:70
msgid "type ``ansible localhost -m my_local_module`` to see the output for that module, or"
msgstr "``ansible localhost -m my_local_module`` と入力すると、そのモジュールの出力が表示されます。あるいは、"

#: ../../rst/dev_guide/developing_locally.rst:71
msgid "type ``ansible-doc -t module my_local_module`` to see the documentation for that module"
msgstr "``ansible-doc -t module my_local_module`` と入力すると、そのモジュールのドキュメントが表示されます。"

#: ../../rst/dev_guide/developing_locally.rst:75
msgid "Currently, the ``ansible-doc`` command can parse module documentation only from modules written in Python. If you have a module written in a programming language other than Python, please write the documentation in a Python file adjacent to the module file."
msgstr "現在、``ansible-doc`` コマンドは、Python で記述されたモジュールからのみモジュールドキュメントを解析できます。Python 以外のプログラミング言語で記述されたモジュールがある場合は、モジュールファイルの横の Python ファイルにドキュメントを作成してください。"

#: ../../rst/dev_guide/developing_locally.rst:78
msgid "Adding standalone local modules for selected playbooks or a single role"
msgstr "選択したプレイブックや単一のロールへのスタンドアロンのローカルモジュールの追加"

#: ../../rst/dev_guide/developing_locally.rst:80
msgid "Ansible automatically loads all executable files from certain directories adjacent to your playbook or role as modules. Standalone modules in these locations are available only to the specific playbook, playbooks, or role in the parent directory."
msgstr "Ansibleは、Playbookやロールに隣接する特定のディレクトリにあるすべての実行可能ファイルをモジュールとして自動的に読み込みます。これらの場所にあるスタンドアロンのモジュールは、親ディレクトリにある特定のPlaybookまたはロールでのみ利用できます。"

#: ../../rst/dev_guide/developing_locally.rst:82
msgid "To use a standalone module only in a selected playbook or playbooks, store the module in a subdirectory called ``library`` in the directory that contains the playbook or playbooks."
msgstr "スタンドアロンモジュールを特定のプレイブックでのみ使用するには、Playbookを含むディレクトリ内の``library`` というサブディレクトリにモジュールを保存します。"

#: ../../rst/dev_guide/developing_locally.rst:83
msgid "To use a standalone module only in a single role, store the module in a subdirectory called ``library`` within that role."
msgstr "スタンドアロンモジュールを単一のロールでのみ使用するには、そのロール内の``library`` というサブディレクトリにモジュールを保存します。"

#: ../../rst/dev_guide/developing_locally.rst:87
msgid "Roles contained in collections cannot contain any modules or other plugins. All plugins in a collection must live in the collection ``plugins`` directory tree. All plugins in that tree are accessible to all roles in the collection. If you are developing new modules, we recommend distributing them in :ref:`collections <developing_collections>`, not in roles."
msgstr "コレクションに含まれるロールは、モジュールや他のプラグインを含むことができません。コレクション内のすべてのプラグインは、コレクションの``plugins`` ディレクトリツリーに格納されている必要があります。そのツリー内のすべてのプラグインは、コレクション内のすべてのロールからアクセス可能です。新しいモジュールを開発している場合は、ロールではなく、:ref:`collections <developing_collections>` で配布することをお勧めします。"

#: ../../rst/dev_guide/developing_locally.rst:93
msgid "Adding a non-module plugin locally outside of a collection"
msgstr "モジュール以外のプラグインのコレクション外でのローカルでの追加"

#: ../../rst/dev_guide/developing_locally.rst:95
msgid "You can configure Ansible to load standalone local plugins in a specified location or locations and make them available to all playbooks and roles. Alternatively, you can make a standalone local plugin available only to specific playbooks or roles."
msgstr "指定した場所のスタンドアロンのローカルプラグインを読みこむようにAnsibleを設定し、すべてのPlaybookやロールで利用できるようにすることができます。また、スタンドアロンのローカルプラグインを特定のPlaybookやロールでのみ利用できるようにすることもできます。"

#: ../../rst/dev_guide/developing_locally.rst:99
msgid "Although modules are plugins, the naming patterns for directory names and environment variables that apply to other plugin types do not apply to modules. See :ref:`local_modules`."
msgstr "モジュールはプラグインですが、他のプラグインタイプに適用されるディレクトリ名や環境変数のネーミングパターンは、モジュールには適用されません。:ref:`local_modules` をご覧ください。"

#: ../../rst/dev_guide/developing_locally.rst:102
msgid "Adding local non-module plugins for all playbooks and roles"
msgstr "すべてのPlaybookとロールへのローカルのモジュール以外のプラグインの追加"

#: ../../rst/dev_guide/developing_locally.rst:104
msgid "To load standalone local plugins automatically and make them available to all playbooks and roles, use the configuration setting or environment variable for the type of plugin you are adding. These configuration settings and environment variables take a colon-separated list, similar to ``$PATH``. You have two options:"
msgstr "スタンドアロンのローカルプラグインを自動的に読み込み、すべてのPlaybookとロールで利用できるようにするには、追加するプラグインのタイプの構成設定または環境変数を使用します。``$PATH`` と同様に、これらの構成設定や環境変数はコロンで区切られたリストを受け取ります。2つのオプションがあります。"

#: ../../rst/dev_guide/developing_locally.rst:106
msgid "Add your local plugin to one of the default configured locations. See :ref:`configuration settings <ansible_configuration_settings>` for details on the correct configuration setting for the plugin type. Default locations may change without notice."
msgstr "ローカルプラグインを、デフォルトで設定されている場所の1つに追加します。プラグインタイプの正しい構成設定の詳細については、:ref:`configuration settings <ansible_configuration_settings>` をご覧ください。デフォルトのロケーションは予告なく変更されることがあります。"

#: ../../rst/dev_guide/developing_locally.rst:109
msgid "Add the location of your local plugin to an environment variable or configuration:"
msgstr "ローカルプラグインの場所を、環境変数や設定に追加します。"

#: ../../rst/dev_guide/developing_locally.rst:108
msgid "the relevant ``ANSIBLE_plugin_type_PLUGINS`` environment variable - for example, ``$ANSIBLE_INVENTORY_PLUGINS`` or ``$ANSIBLE_VARS_PLUGINS``"
msgstr "関連する``ANSIBLE_plugin_type_PLUGINS`` 環境変数 - 例えば、``$ANSIBLE_INVENTORY_PLUGINS`` または ``$ANSIBLE_VARS_PLUGINS``"

#: ../../rst/dev_guide/developing_locally.rst:109
msgid "the relevant ``plugin_type_PATH`` configuration setting, most of which begin with ``DEFAULT_`` - for example, ``DEFAULT_CALLBACK_PLUGIN_PATH`` or ``DEFAULT_FILTER_PLUGIN_PATH`` or ``BECOME_PLUGIN_PATH``"
msgstr "関連する``plugin_type_PATH`` 構成設定（ほとんどが``DEFAULT_`` で始まる）- 例えば``DEFAULT_CALLBACK_PLUGIN_PATH`` や``DEFAULT_FILTER_PLUGIN_PATH`` や ``BECOME_PLUGIN_PATH``"

#: ../../rst/dev_guide/developing_locally.rst:111
msgid "To view your current configuration settings for non-module plugins:"
msgstr "モジュール以外のプラグインの現在の構成設定を表示するには："

#: ../../rst/dev_guide/developing_locally.rst:117
msgid "After your plugin file is added to one of these locations, Ansible loads it and you can use it in any local module, task, playbook, or role. For more information on environment variables and configuration settings, see :ref:`ansible_configuration_settings`."
msgstr "プラグインファイルがこれらの場所のいずれかに追加されると、Ansible はそのファイルをロードし、任意のローカルモジュール、タスク、Playbook、ロールで使用できるようになります。環境変数および構成設定の詳細については、:ref:`ansible_configuration_settings` を参照してください。"

#: ../../rst/dev_guide/developing_locally.rst:119
msgid "To confirm that ``plugins/plugin_type/my_local_plugin`` is available:"
msgstr "``plugins/plugin_type/my_local_plugin`` が利用可能であることを確認するには："

#: ../../rst/dev_guide/developing_locally.rst:121
msgid "type ``ansible-doc -t <plugin_type> my_local_lookup_plugin`` to see the documentation for that plugin - for example, ``ansible-doc -t lookup my_local_lookup_plugin``"
msgstr "``ansible-doc -t <plugin_type> my_local_lookup_plugin`` と入力すると、そのプラグインのドキュメントが表示されます （例：``ansible-doc -t lookup my_local_lookup_plugin``）。"

#: ../../rst/dev_guide/developing_locally.rst:123
msgid "The ``ansible-doc`` command works for most plugin types, but not for action, filter, or test plugins. See :ref:`ansible-doc` for more details."
msgstr "``ansible-doc`` コマンドは、ほとんどの種類のプラグインで動作しますが、アクション、フィルター、テストプラグインでは動作しません。詳しくは:ref:`ansible-doc` をご覧ください。"

#: ../../rst/dev_guide/developing_locally.rst:126
msgid "Adding standalone local plugins for selected playbooks or a single role"
msgstr "選択したプレイブックや単一のロールへのスタンドアロンのローカルプラグインの追加"

#: ../../rst/dev_guide/developing_locally.rst:128
msgid "Ansible automatically loads all plugins from certain directories adjacent to your playbook or role, loading each type of plugin separately from a directory named for the type of plugin. Standalone plugins in these locations are available only to the specific playbook, playbooks, or role in the parent directory."
msgstr "Ansibleは、Playbookやロールに隣接する特定のディレクトリにあるすべてのプラグインを自動的に読み込みます。各タイプのプラグインは、プラグインのタイプの名前が付いたディレクトリーから個別に読み込まれます。これらの場所にあるスタンドアロンのプラグインは、親ディレクトリにある特定のPlaybookまたはロールでのみ利用できます。"

#: ../../rst/dev_guide/developing_locally.rst:130
msgid "To use a standalone plugin only in a selected playbook or playbooks, store the plugin in a subdirectory for the correct ``plugin_type`` (for example, ``callback_plugins`` or ``inventory_plugins``) in the directory that contains the playbooks. These directories must use the ``_plugins`` suffix. For a full list of plugin types, see :ref:`working_with_plugins`."
msgstr "選択した Playbookでのみスタンドアロンのプラグインを使用するには、そのPlaybook を含むディレクトリーの正しい ``plugin_type``のサブディレクトリー (例: ``callback_plugins`` または ``inventory_plugins``) にプラグインを保存します。これらのディレクトリーは、``_plugins``の接尾辞を使用する必要があります。プラグインタイプの完全なリストは、:ref:`working_with_plugins`を参照してください。"

#: ../../rst/dev_guide/developing_locally.rst:131
msgid "To use a standalone plugin only in a single role, store the plugin in a subdirectory for the correct ``plugin_type`` (for example, ``cache_plugins`` or ``strategy_plugins``) within that role. When shipped as part of a role, the plugin is available as soon as the role is executed. These directories must use the ``_plugins`` suffix. For a full list of plugin types, see :ref:`working_with_plugins`."
msgstr "単一のロールでのみスタンドアロンのプラグインを使用するには、そのロール内の正しい ``plugin_type`` のサブディレクトリー （例：``cache_plugins`` または ``strategy_plugins``) にプラグインを保存します。ロールの一部として提供された場合は、ロールが実行されるとすぐにプラグインが利用可能になります。これらのディレクトリーは、``_plugins``の接尾辞を使用する必要があります。プラグインタイプの完全なリストは、:ref:`working_with_plugins`を参照してください。"

#: ../../rst/dev_guide/developing_locally.rst:135
msgid "Roles contained in collections cannot contain any plugins. All plugins in a collection must live in the collection ``plugins`` directory tree. All plugins in that tree are accessible to all roles in the collection. If you are developing new plugins, we recommend distributing them in :ref:`collections <developing_collections>`, not in roles."
msgstr "コレクションに含まれるロールは、プラグインを含むことができません。コレクション内のすべてのプラグインは、コレクションの``plugins`` ディレクトリツリーに格納されている必要があります。そのツリー内のすべてのプラグインは、コレクション内のすべてのロールからアクセス可能です。新しいプラグインを開発している場合は、ロールではなく、:ref:`collections <developing_collections>` で配布することをお勧めします。"

#: ../../rst/dev_guide/developing_locally.rst:140
msgid "Using ``ansible.legacy`` to access custom versions of an ``ansible.builtin`` module"
msgstr "``ansible.legacy`` を使用した ``ansible.builtin`` モジュールのカスタムバージョンへのアクセス"

#: ../../rst/dev_guide/developing_locally.rst:142
msgid "If you need to override one of the ``ansible.builtin`` modules and are using FQCN, you need to use ``ansible.legacy`` as part of the fully-qualified collection name (FQCN). For example, if you had your own ``copy`` module, you would access it as ``ansible.legacy.copy``. See :ref:`using_ansible_legacy` for details on how to use custom modules with roles within a collection."
msgstr "``ansible.builtin`` モジュールのいずれかをオーバーライドする必要があり、FQCN を使用している場合は、完全修飾コレクション名 (FQCN) の一部として ``ansible.legacy`` を使用する必要があります。たとえば、独自の ``copy`` モジュールがある場合は、``ansible.legacy.copy`` としてアクセスします。コレクション内のロールでカスタムモジュールを使用する方法は、:ref:`using_ansible_legacy` を参照してください。"

#: ../../rst/dev_guide/developing_module_utilities.rst:5
msgid "Using and developing module utilities"
msgstr "モジュールユーティリティーの使用および開発"

#: ../../rst/dev_guide/developing_module_utilities.rst:7
msgid "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``:"
msgstr "Ansible は、独自のモジュール開発時に使用できるヘルパー関数を提供する多くのモジュールユーティリティー、または共有コードのスニペットを提供します。``basic.py`` モジュールユーティリティーは、Ansible ライブラリーにアクセスするためのメインのエントリーポイントを提供します。また、すべての Python Ansible モジュールは ``ansible.module_utils`` からインポートする必要があります。一般的なオプションでは、``AnsibleModule`` をインポートするのが一般的です。"

#: ../../rst/dev_guide/developing_module_utilities.rst:17
msgid "The ``ansible.module_utils`` namespace is not a plain Python package: it is constructed dynamically for each task invocation, by extracting imports and resolving those matching the namespace against a :ref:`search path <ansible_search_path>` derived from the active configuration."
msgstr "``ansible.module_utils`` 名前空間は単純な Python パッケージではありません。これは、インポートを抽出し、アクティブな設定から派生する :ref:`検索パス <ansible_search_path>` に対して一致する名前空間を解決することで、各タスク呼び出し用に動的に構築されます。"

#: ../../rst/dev_guide/developing_module_utilities.rst:22
msgid "To reduce the maintenance burden in a collection or in local modules, you can extract duplicated code into one or more module utilities and import them into your modules. For example, if you have your own custom modules that import a ``my_shared_code`` library, you can place that into a ``./module_utils/my_shared_code.py`` file like this::"
msgstr "コレクションまたはローカルモジュールのメンテナンス負荷を軽減するには、重複コードを 1 つ以上のモジュールユーティリティーに抽出してモジュールにインポートすることができます。たとえば、``my_shared_code`` ライブラリーをインポートする独自のカスタムモジュールがある場合は、これを、以下のように ``./module_utils/my_shared_code.py`` ファイルに配置できます。"

#: ../../rst/dev_guide/developing_module_utilities.rst:27
msgid "When you run ``ansible-playbook``, Ansible will merge any files in your local ``module_utils`` directories into the ``ansible.module_utils`` namespace in the order defined by the :ref:`Ansible search path <ansible_search_path>`."
msgstr "``ansible-playbook`` を実行すると、Ansible は :ref:`Ansible 検索パス <ansible_search_path>` で定義されている順序でローカルの ``module_utils`` ディレクトリーのファイルを ``ansible.module_utils`` 名前空間にマージします。"

#: ../../rst/dev_guide/developing_module_utilities.rst:30
msgid "Naming and finding module utilities"
msgstr "モジュールユーティリティーの命名および検索"

#: ../../rst/dev_guide/developing_module_utilities.rst:32
msgid "You can generally tell what a module utility does from its name and/or its location. Generic utilities (shared code used by many different kinds of modules) live in the main ansible/ansible codebase, in the ``common`` subdirectory or in the root directory of ``lib/ansible/module_utils``. Utilities used by a particular set of modules generally live in the same collection as those modules. For example:"
msgstr "通常、モジュールユーティリティーが名前やその場所から動作するようにできます。汎用ユーティリティー (さまざまな種類のモジュールで使用される共有コード) は、メインの ansible/ansible コードベースにあります。``common`` サブディレクトリー、または ``lib/ansible/module_utils`` のルートディレクトリーにあります。特定のモジュールセットで使用されるユーティリティーは、通常、それらのモジュールと同じコレクションに存在します。以下に例を示します。"

#: ../../rst/dev_guide/developing_module_utilities.rst:34
msgid "``lib/ansible/module_utils/urls.py`` contains shared code for parsing URLs"
msgstr "``lib/ansible/module_utils/urls.py`` は、URL を解析するための共有コードが含まれています。"

#: ../../rst/dev_guide/developing_module_utilities.rst:35
msgid "``openstack.cloud.plugins.module_utils.openstack.py`` contains utilities for modules that work with OpenStack instances"
msgstr "``openstack.cloud.plugins.module_utils.openstack.py`` には、OpenStack インスタンスと連携するモジュールのユーティリティーが含まれます。"

#: ../../rst/dev_guide/developing_module_utilities.rst:36
msgid "``ansible.netcommon.plugins.module_utils.network.common.config.py`` contains utility functions for use by networking modules"
msgstr "``ansible.netcommon.plugins.module_utils.network.common.config.py`` は、ネットワークモジュールによって使用される設定ユーティリティーの機能が含まれます。"

#: ../../rst/dev_guide/developing_module_utilities.rst:38
msgid "Following this pattern with your own module utilities makes everything easy to find and use."
msgstr "このパターンを独自のモジュールユーティリティーで行うと、あらゆるものを見つけ、使用することが容易になります。"

#: ../../rst/dev_guide/developing_module_utilities.rst:43
msgid "Standard module utilities"
msgstr "標準のモジュールユーティリティー"

#: ../../rst/dev_guide/developing_module_utilities.rst:45
msgid "Ansible ships with an extensive library of ``module_utils`` files. You can find the module utility source code in the ``lib/ansible/module_utils`` directory under your main Ansible path. We describe the most widely used utilities below. For more details on any specific module utility, please see the `source code for module_utils <https://github.com/ansible/ansible/tree/devel/lib/ansible/module_utils>`_."
msgstr "Ansible には、``module_utils`` ファイルの広範なライブラリーが含まれています。モジュールユーティリティーのソースコードは、メインの Ansible パス下の ``lib/ansible/module_utils`` ディレクトリーにあります。また、以下で最も広く使用されているユーティリティーが含まれています。特定のモジュールユーティリティーの詳細は、「`モジュールユーティリティーのソースコード <https://github.com/ansible/ansible/tree/devel/lib/ansible/module_utils>`_」を参照してください。"

#: ../../rst/dev_guide/shared_snippets/licensing.txt:2
msgid "**LICENSING REQUIREMENTS**  Ansible enforces the following licensing requirements:"
msgstr "**ライセンス要件** Ansible は、以下のライセンス要件を強制します。"

#: ../../rst/dev_guide/shared_snippets/licensing.txt:7
msgid "Utilities (files in ``lib/ansible/module_utils/``) may have one of two licenses:"
msgstr "ユーティリティー (``lib/ansible/module_utils/`` 内のファイル) には、2 つあるライセンスのいずれかが存在する可能性があります。"

#: ../../rst/dev_guide/shared_snippets/licensing.txt:5
msgid "A file in ``module_utils`` used **only** for a specific vendor's hardware, provider, or service may be licensed under GPLv3+. Adding a new file under ``module_utils`` with GPLv3+ needs to be approved by the core team."
msgstr "特定のベンダーのハードウェア、プロバイダー、またはサービスに **のみ** ``module_utils`` を使用するファイルは、GPLv3 以降でライセンスを取得している可能性があります。GPLv3 以降を持つ ``module_utils`` に新しいファイルを追加するには、コアチームによる承認が必要になります。"

#: ../../rst/dev_guide/shared_snippets/licensing.txt:7
msgid "All other ``module_utils`` must be licensed under BSD, so GPL-licensed third-party and Galaxy modules can use them."
msgstr "他のすべての ``module_utils`` は、GPL のライセンスが付与されたサードパーティーと Galaxy モジュールが使用できるように、BSD でライセンスが付与されている必要があります。"

#: ../../rst/dev_guide/shared_snippets/licensing.txt:8
msgid "If there's doubt about the appropriate license for a file in ``module_utils``, the Ansible Core Team will decide during an Ansible Core Community Meeting."
msgstr "``module_utils`` のファイルに適切なライセンスについて疑問がある場合は、Ansible Core Team が Ansible Core Community Meeting で決定します。"

#: ../../rst/dev_guide/shared_snippets/licensing.txt:9
msgid "All other files shipped with Ansible, including all modules, must be licensed under the GPL license (GPLv3 or later)."
msgstr "すべてのモジュールを含む Ansible に同梱される他のすべてのファイルは、GPL ライセンス (GPLv3 以降) でライセンスを取得する必要があります。"

#: ../../rst/dev_guide/shared_snippets/licensing.txt:10
msgid "Existing license requirements still apply to content in ansible/ansible (ansible-core)."
msgstr "既存のライセンス要件は、引き続き ansible/ansible のコンテンツ (ansible-core) に適用されます。"

#: ../../rst/dev_guide/shared_snippets/licensing.txt:11
msgid "Content that was previously in ansible/ansible or a collection and has moved to a new collection must retain the license it had in its prior repository."
msgstr "コンテンツが過去に ansible/ansible またはコレクションにあり、新しいコレクションに移動した場合は、以前のリポジトリーのライセンスを保持する必要があります。"

#: ../../rst/dev_guide/shared_snippets/licensing.txt:12
msgid "Copyright entries by previous committers must also be kept in any moved files."
msgstr "以前のコミット担当者による著作権エントリーも、移動したファイルに保持する必要があります。"

#: ../../rst/dev_guide/developing_module_utilities.rst:49
msgid "``api.py`` - Supports generic API modules"
msgstr "``api.py`` - 汎用 API モジュールのサポート"

#: ../../rst/dev_guide/developing_module_utilities.rst:50
msgid "``basic.py`` - General definitions and helper utilities for Ansible modules"
msgstr "``basic.py`` - Ansible モジュールの一般的な定義およびヘルパーユーティリティー"

#: ../../rst/dev_guide/developing_module_utilities.rst:51
msgid "``common/dict_transformations.py`` - Helper functions for dictionary transformations"
msgstr "``common/dict_transformations.py`` - ディクショナリー変換のヘルパー関数"

#: ../../rst/dev_guide/developing_module_utilities.rst:52
msgid "``common/file.py`` - Helper functions for working with files"
msgstr "``common/file.py`` - ファイルを操作するヘルパー関数"

#: ../../rst/dev_guide/developing_module_utilities.rst:53
msgid "``common/text/`` - Helper functions for converting and formatting text"
msgstr "``common/text/`` - テキストの変換およびフォーマットを行うためのヘルパー関数"

#: ../../rst/dev_guide/developing_module_utilities.rst:54
msgid "``common/parameters.py`` - Helper functions for dealing with module parameters"
msgstr "``common/parameters.py`` - モジュールパラメーターを処理するヘルパー関数"

#: ../../rst/dev_guide/developing_module_utilities.rst:55
msgid "``common/sys_info.py`` - Functions for getting distribution and platform information"
msgstr "``common/sys_info.py`` - ディストリビューションおよびプラットフォーム情報を取得する機能"

#: ../../rst/dev_guide/developing_module_utilities.rst:56
msgid "``common/validation.py`` - Helper functions for validating module parameters against a module argument spec"
msgstr "``common/validation.py`` - モジュール引数仕様に対してモジュールパラメーターを検証するためのヘルパー関数"

#: ../../rst/dev_guide/developing_module_utilities.rst:57
msgid "``facts/`` - Directory of utilities for modules that return facts. See `PR 23012 <https://github.com/ansible/ansible/pull/23012>`_ for more information"
msgstr "``facts/`` - ファクトを返すモジュールのユーティリティーのディレクトリー。詳細は、`PR 23012 <https://github.com/ansible/ansible/pull/23012>`_ を参照してください。"

#: ../../rst/dev_guide/developing_module_utilities.rst:58
msgid "``json_utils.py`` - Utilities for filtering unrelated output around module JSON output, like leading and trailing lines"
msgstr "``json_utils.py`` - 先頭行や末尾行など、モジュール JSON 出力に関する関連のない出力をフィルターを設定するユーティリティー"

#: ../../rst/dev_guide/developing_module_utilities.rst:59
msgid "``powershell/`` - Directory of definitions and helper functions for Windows PowerShell modules"
msgstr "``powershell/`` - Windows PowerShell モジュールの定義およびヘルパー関数のディレクトリー"

#: ../../rst/dev_guide/developing_module_utilities.rst:60
msgid "``pycompat24.py`` - Exception workaround for Python 2.4"
msgstr "``pycompat24.py`` - Python 2.4 の例外回避策"

#: ../../rst/dev_guide/developing_module_utilities.rst:61
msgid "``service.py`` - Utilities to enable modules to work with Linux services (placeholder, not in use)"
msgstr "``service.py`` - モジュールが Linux サービスと連携できるようにするユーティリティー (未使用のプレースホルダー)"

#: ../../rst/dev_guide/developing_module_utilities.rst:62
msgid "``six/__init__.py`` - Bundled copy of the `Six Python library <https://pypi.org/project/six/>`_ to aid in writing code compatible with both Python 2 and Python 3"
msgstr "``six/__init__.py`` - Python 2 と Python 3 の両方と互換性のあるコードを書き込む際に助けとなる `Six Python ライブラリー <https://pypi.org/project/six/>`_ のバンドルコピー"

#: ../../rst/dev_guide/developing_module_utilities.rst:63
msgid "``splitter.py`` - String splitting and manipulation utilities for working with Jinja2 templates"
msgstr "``splitter.py`` - Jinja2 テンプレートを使用する文字列分割および操作ユーティリティー"

#: ../../rst/dev_guide/developing_module_utilities.rst:64
msgid "``urls.py`` - Utilities for working with http and https requests"
msgstr "``urls.py`` - http および https リクエストを操作するユーティリティー"

#: ../../rst/dev_guide/developing_module_utilities.rst:66
msgid "Several commonly-used utilities migrated to collections in Ansible 2.10, including:"
msgstr "一般的に使用されるいくつかのユーティリティーは、Ansible 2.10 では以下のようなコレクションに移行されています。"

#: ../../rst/dev_guide/developing_module_utilities.rst:68
msgid "``ismount.py`` migrated to ``ansible.posix.plugins.module_utils.mount.py`` - Single helper function that fixes os.path.ismount"
msgstr "``ansible.posix.plugins.module_utils.mount.py`` に移行した ``ismount.py`` - os.path.ismount を修正する単一のヘルパー関数"

#: ../../rst/dev_guide/developing_module_utilities.rst:69
msgid "``known_hosts.py`` migrated to ``community.general.plugins.module_utils.known_hosts.py`` - utilities for working with known_hosts file"
msgstr "``community.general.plugins.module_utils.known_hosts.py`` に移行した ``known_hosts.py`` - known_hosts ファイルで作業するためのユーティリティー"

#: ../../rst/dev_guide/developing_module_utilities.rst:71
msgid "For a list of migrated content with destination collections, see https://github.com/ansible/ansible/blob/devel/lib/ansible/config/ansible_builtin_runtime.yml."
msgstr "宛先コレクションで移行されたコンテンツの一覧は、https://github.com/ansible/ansible/blob/devel/lib/ansible/config/ansible_builtin_runtime.yml を参照してください。"

#: ../../rst/dev_guide/developing_modules.rst:6
msgid "Should you develop a module?"
msgstr "モジュール開発の必要性"

#: ../../rst/dev_guide/developing_modules.rst:8
msgid "Developing Ansible modules is easy, but often it is not necessary. Before you start writing a new module, ask:"
msgstr "Ansible モジュールの開発は容易ですが、通常は不要です。新しいモジュールを書き始める前に、以下を確認してください。"

#: ../../rst/dev_guide/developing_modules.rst:10
msgid "Does a similar module already exist?"
msgstr "同様のモジュールが存在しているか。"

#: ../../rst/dev_guide/developing_modules.rst:12
msgid "An existing module may cover the functionality you want. Ansible collections include thousands of modules. Search our :ref:`list of included collections <list_of_collections>` or `Ansible Galaxy <https://galaxy.ansible.com>`_ to see if an existing module does what you need."
msgstr "既存のモジュールは必要な機能に対応できます。Ansible コレクションには、数千のモジュールが含まれています。:ref:`同梱されるコレクションの一覧 <list_of_collections>` または `Ansible Galaxy <https://galaxy.ansible.com>`_ を検索すると、既存のモジュールが必要なモジュールかどうかが分かります。"

#: ../../rst/dev_guide/developing_modules.rst:14
msgid "Should you use or develop an action plugin instead of a module?"
msgstr "モジュールの代わりにアクションプラグインを使用するか、または開発する必要があるか。"

#: ../../rst/dev_guide/developing_modules.rst:16
msgid "An action plugin may be the best way to get the functionality you want. Action plugins run on the control node instead of on the managed node, and their functionality is available to all modules. For more information about developing plugins, read the :ref:`developing plugins page <developing_plugins>`."
msgstr "アクションプラグインは、必要な機能を取得する最善の方法となるでしょう。アクションプラグインは、管理ノードではなくコントロールノードで実行され、その機能はすべてのモジュールで利用できます。プラグインの開発に関する詳細は、「:ref:`プラグインの開発ページ<developing_plugins>`」を参照してください。"

#: ../../rst/dev_guide/developing_modules.rst:18
msgid "Should you use a role instead of a module?"
msgstr "モジュールの代わりにロールを使用する必要があるか。"

#: ../../rst/dev_guide/developing_modules.rst:20
msgid "A combination of existing modules may cover the functionality you want. You can write a role for this type of use case. Check out the :ref:`roles documentation<playbooks_reuse_roles>`."
msgstr "既存のモジュールの組み合わせによって、希望の機能に対応できる可能性があります。このタイプのユースケースにロールを作成することができます。「:ref:`ロールのドキュメント<playbooks_reuse_roles>`」を確認してください。"

#: ../../rst/dev_guide/developing_modules.rst:22
msgid "Should you create a collection instead of a single module?"
msgstr "1 つのモジュールの代わりにコレクションを作成する必要があるか。"

#: ../../rst/dev_guide/developing_modules.rst:24
msgid "The functionality you want may be too large for a single module. If you want to connect Ansible to a new cloud provider, database, or network platform, you may need to :ref:`develop a new collection<developing_modules_in_groups>`."
msgstr "1 つのモジュールでは、この機能が大きすぎる可能性があります。Ansible を新しいクラウドプロバイダー、データベース、またはネットワークプラットフォームに接続する場合は、:ref:`新しいコレクションの開発<developing_modules_in_groups>` が必要になる場合があります。"

#: ../../rst/dev_guide/developing_modules.rst:26
msgid "Each module should have a concise and well defined functionality. Basically, follow the UNIX philosophy of doing one thing well."
msgstr "各モジュールには、簡潔で十分に機能が定義されている必要があります。基本的には、1 つのことを十分に行うという UNIX の哲学に従ってください。"

#: ../../rst/dev_guide/developing_modules.rst:28
msgid "A module should not require that a user know all the underlying options of an API/tool to be used. For instance, if the legal values for a required module parameter cannot be documented, that's a sign that the module would be rejected."
msgstr "モジュールは、使用する API またはツールの基礎となるすべてのオプションを把握する必要がありません。たとえば、必要なモジュールパラメーターの有効な値を文書化できない場合、それはモジュールが拒否されることを示しています。"

#: ../../rst/dev_guide/developing_modules.rst:30
msgid "Modules should typically encompass much of the logic for interacting with a resource. A lightweight wrapper around an API that does not contain much logic would likely cause users to offload too much logic into a playbook, and for this reason the module would be rejected. Instead try creating multiple modules for interacting with smaller individual pieces of the API."
msgstr "モジュールは、通常、リソースと対話するロジックの多くを網羅する必要があります。ロジックをあまり含まない API の軽量ラッパーを使用すると、ユーザーがあまりにも多くのロジックを Playbook にオフロードする原因となる可能性があるため、モジュールが拒否されます。代わりに、API の小さな個々の部分と対話するための複数のモジュールを作成してみてください。"

#: ../../rst/dev_guide/developing_modules.rst:32
msgid "If your use case isn't covered by an existing module, an action plugin, or a role, and you don't need to create multiple modules, then you're ready to start developing a new module. Choose from the topics below for next steps:"
msgstr "ユースケースが、既存のモジュール、アクションプラグイン、またはロールでは対応されておらず、複数のモジュールを作成する必要がない場合は、新しいモジュールの開発を開始する準備ができています。次のステップは、以下のトピックから選択します。"

#: ../../rst/dev_guide/developing_modules.rst:34
msgid "I want to :ref:`get started on a new module <developing_modules_general>`."
msgstr ":ref:`新しいモジュールを使用開始<developing_modules_general>` したいです。"

#: ../../rst/dev_guide/developing_modules.rst:35
msgid "I want to review :ref:`tips and conventions for developing good modules <developing_modules_best_practices>`."
msgstr ":ref:`良質なモジュールを開発するためのヒントおよび規約 <developing_modules_best_practices>` を確認します。"

#: ../../rst/dev_guide/developing_modules.rst:36
msgid "I want to :ref:`write a Windows module <developing_modules_general_windows>`."
msgstr ":ref:`Windows モジュールを作成 <developing_modules_general_windows>` したいです。"

#: ../../rst/dev_guide/developing_modules.rst:37
msgid "I want :ref:`an overview of Ansible's architecture <developing_program_flow_modules>`."
msgstr ":ref:`Ansible のアーキテクチャーの概要 <developing_program_flow_modules>` が必要です。"

#: ../../rst/dev_guide/developing_modules.rst:38
msgid "I want to :ref:`document my module <developing_modules_documenting>`."
msgstr ":ref:`作成したモジュールをドキュメント化 <developing_modules_documenting>` したいです。"

#: ../../rst/dev_guide/developing_modules.rst:39
msgid "I want to :ref:`contribute my module to an existing Ansible collection <developing_modules_checklist>`."
msgstr ":ref:`自分のモジュールで既存の Ansible コレクションに貢献 <developing_modules_checklist>` したいです。"

#: ../../rst/dev_guide/developing_modules.rst:40
msgid "I want to :ref:`add unit and integration tests to my module <developing_testing>`."
msgstr ":ref:`作成したモジュールにユニットテストおよび統合テストを追加 <developing_testing>` したいです。"

#: ../../rst/dev_guide/developing_modules.rst:41
msgid "I want to :ref:`add Python 3 support to my module <developing_python_3>`."
msgstr ":ref:`作成したモジュールに Python 3 サポートを追加 <developing_python_3>` したいです。"

#: ../../rst/dev_guide/developing_modules.rst:42
msgid "I want to :ref:`write multiple modules <developing_modules_in_groups>`."
msgstr ":ref:`複数モジュールを作成 <developing_modules_in_groups>` したいです。"

#: ../../rst/dev_guide/developing_modules.rst:46
#: ../../rst/dev_guide/developing_plugins.rst:538
msgid ":ref:`list_of_collections`"
msgstr ":ref:`list_of_collections`"

#: ../../rst/dev_guide/developing_modules.rst:47
#: ../../rst/dev_guide/developing_plugins.rst:539
msgid "Browse existing collections, modules, and plugins"
msgstr "既存のコレクション、モジュール、およびプラグインの閲覧"

#: ../../rst/dev_guide/developing_modules.rst:49
msgid "Development mailing list"
msgstr "開発メーリングリスト"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:6
msgid "Conventions, tips, and pitfalls"
msgstr "規則、ヒント、および落とし穴"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:11
msgid "As you design and develop modules, follow these basic conventions and tips for clean, usable code:"
msgstr "モジュールの設計および開発を行う際に、以下の基本的な規則およびヒントに従って、読みやすく使用可能なコードを作成します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:14
msgid "Scoping your module(s)"
msgstr "モジュールのスコープ設定"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:16
msgid "Especially if you want to contribute your module(s) to an existing Ansible Collection, make sure each module includes enough logic and functionality, but not too much. If these guidelines seem confusing, consider :ref:`whether you really need to write a module <module_dev_should_you>` at all."
msgstr "特に、既存の Ansible Collection にモジュールを提供する場合は、各モジュールに十分なロジックと機能が含まれていることを確認してください。ただし、多すぎないようにしてください。これらのガイドラインが紛らわしいと思われる場合は、:ref:`モジュールの記述が本当に必要かどうか <module_dev_should_you>` を検討してください。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:18
msgid "Each module should have a concise and well-defined functionality. Basically, follow the UNIX philosophy of doing one thing well."
msgstr "各モジュールには、簡潔で十分に機能が定義されている必要があります。基本的には、1 つのことを十分に行うという UNIX の哲学に従ってください。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:19
msgid "Do not add ``get``, ``list`` or ``info`` state options to an existing module - create a new ``_info`` or ``_facts`` module."
msgstr "既存のモジュールに、``get``、``list``、または ``info`` の状態のオプションを追加しないでください。新しい ``_info`` モジュールまたは ``_facts`` モジュールを作成します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:20
msgid "Modules should not require that a user know all the underlying options of an API/tool to be used. For instance, if the legal values for a required module option cannot be documented, the module does not belong in Ansible Core."
msgstr "モジュールでは、使用する API またはツールの基礎となるオプションをすべてユーザーが把握する必要がありません。たとえば、必要なモジュールオプションの有効な値を文書化できない場合、そのモジュールは Ansible Core に属しません。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:21
msgid "Modules should encompass much of the logic for interacting with a resource. A lightweight wrapper around a complex API forces users to offload too much logic into their playbooks. If you want to connect Ansible to a complex API, :ref:`create multiple modules <developing_modules_in_groups>` that interact with smaller individual pieces of the API."
msgstr "モジュールは、リソースと対話するためのロジックを多数組み込む必要があります。複雑な API に関連した軽量ラッパーにより、ユーザーは Playbook に非常に多くのロジックをオフロードします。Ansible を複雑な API に接続する場合は、API のより小さい個々の部分と対話する :ref:`複数のモジュールを作成 <developing_modules_in_groups>` します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:22
msgid "Avoid creating a module that does the work of other modules; this leads to code duplication and divergence, and makes things less uniform, unpredictable and harder to maintain. Modules should be the building blocks. If you are asking 'how can I have a module execute other modules' ... you want to write a role."
msgstr "他のモジュールの作業を行うモジュールを作成しないようにしてください。これにより、コードの重複と差異が発生し、一貫性が保たれず、予測ができなくなり、維持が難しくなります。モジュールはビルディングブロックでなければなりません。「どのようにしてモジュールに他のモジュールを実行させることができるのか」という質問が浮かんでくる場合は、それがロールを作成する理由になります。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:25
msgid "Designing module interfaces"
msgstr "モジュールインターフェースの設計"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:27
msgid "If your module is addressing an object, the option for that object should be called ``name`` whenever possible, or accept ``name`` as an alias."
msgstr "モジュールがオブジェクトに対処している場合は、可能な限りそのオブジェクトのオプションを ``name`` とするか、またはエイリアスとして ``name`` を受け入れます。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:28
msgid "Modules accepting boolean status should accept ``yes``, ``no``, ``true``, ``false``, or anything else a user may likely throw at them. The AnsibleModule common code supports this with ``type='bool'``."
msgstr "ブール値ステータスを許可するモジュールは、``yes``、``no``、``true``、``false``、もしくはユーザーに出力される可能性があるものはなんでも受け入れる必要がります。AnsibleModule の一般的なコードは、``type='bool'`` でこれをサポートします。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:29
msgid "Avoid ``action``/``command``, they are imperative and not declarative, there are other ways to express the same thing."
msgstr "``action``/``command`` は使用しないでください。これは命令型であり、宣言的ではありませんが、同じ方法を表示する方法は他にもあります。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:32
msgid "General guidelines & tips"
msgstr "一般的なガイドラインおよびヒント"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:34
msgid "Each module should be self-contained in one file, so it can be auto-transferred by ``ansible-core``."
msgstr "各モジュールは 1 つのファイルにまとめて自己完結させる必要があり、``ansible-core`` で自動転送できるようにします。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:35
msgid "Module name MUST use underscores instead of hyphens or spaces as a word separator. Using hyphens and spaces will prevent ``ansible-core`` from importing your module."
msgstr "モジュール名は、単語の区切り文字として、ハイフンやスペースの代わりにアンダースコアを使用する必要があります。ハイフンやスペースを使用すると、``ansible-core`` がモジュールをインポートできなくなります。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:36
msgid "Always use the ``hacking/test-module.py`` script when developing modules - it will warn you about common pitfalls."
msgstr "モジュールを開発する際には必ず ``hacking/test-module.py`` スクリプトを使用してください。よくある落とし穴について警告してくれます。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:37
msgid "If you have a local module that returns information specific to your installations, a good name for this module is ``site_info``."
msgstr "インストールに固有の情報を返すローカルモジュールがある場合、このモジュールの適切な名前は ``site_info`` となります。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:38
msgid "Eliminate or minimize dependencies. If your module has dependencies, document them at the top of the module file and raise JSON error messages when dependency import fails."
msgstr "依存関係をなくするか、または最小限に抑えます。モジュールに依存関係がある場合は、モジュールファイルの冒頭で文書化し、依存関係のインポートに失敗した場合は JSON エラーメッセージを発生させます。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:39
msgid "Don't write to files directly; use a temporary file and then use the ``atomic_move`` function from ``ansible.module_utils.basic`` to move the updated temporary file into place. This prevents data corruption and ensures that the correct context for the file is kept."
msgstr "ファイルに直接書き込まないようにします。一時ファイルを使用してから、``ansible.module_utils.basic`` の ``atomic_move`` 関数を使用して、更新された一時ファイルを所定の場所に移動させます。これにより、データの破損を防ぎ、ファイルの正しいコンテキストが保持されるようになります。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:40
msgid "Avoid creating caches. Ansible is designed without a central server or authority, so you cannot guarantee it will not run with different permissions, options or locations. If you need a central authority, have it on top of Ansible (for example, using bastion/cm/ci server, AWX, or the Red Hat Ansible Automation Platform); do not try to build it into modules."
msgstr "キャッシュを作成しないでください。Ansible は中央のサーバーや権限を持たないように設計されているため、さまざまなパーミッション、オプション、場所を指定して実行しないことを保証することはできません。中央の権限が必要な場合は、それを Ansible の上に置いてください (例: bastion/cm/ci server、AWX、または Red Hat Ansible Automation Platform を使用)。それをモジュールには組み込まないでください。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:41
msgid "If you package your module(s) in an RPM, install the modules on the control machine in ``/usr/share/ansible``. Packaging modules in RPMs is optional."
msgstr "RPM でモジュールをパッケージ化する場合は、コントロールマシンに ``/usr/share/ansible`` のモジュールをインストールします。RPM でのモジュールのパッケージ化は任意です。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:44
msgid "Functions and Methods"
msgstr "関数およびメソッド"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:46
msgid "Each function should be concise and should describe a meaningful amount of work."
msgstr "各関数は簡潔にし、意味のある作業量を記述する必要があります。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:47
msgid "\"Don't repeat yourself\" is generally a good philosophy."
msgstr "「Don't repeat yourself (繰り返さないこと)」は、通常、適している哲学です。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:48
msgid "Function names should use underscores: ``my_function_name``."
msgstr "関数名はアンダースコアを使用する必要があります (``my_function_name``)。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:49
msgid "The name of each function should describe what the function does."
msgstr "各関数の名前には、関数の機能を記述する必要があります。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:50
msgid "Each function should have a docstring."
msgstr "各関数にはドキュメント文字列 (docstring) が必要です。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:51
msgid "If your code is too nested, that's usually a sign the loop body could benefit from being a function. Parts of our existing code are not the best examples of this at times."
msgstr "コードの入れ子を多用しすぎている場合、それは通常、ループ本体が関数であることから利益が得られる可能性のある兆候です。既存のコードの一部は、時としてこのような例としては最適ではありません。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:54
msgid "Python tips"
msgstr "Python のヒント"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:56
msgid "Include a ``main`` function that wraps the normal execution."
msgstr "通常の実行をラップする ``main`` 関数を含めます。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:57
msgid "Call your ``main`` function from a conditional so you can import it into unit tests - for example:"
msgstr "条件から ``main`` 機能を呼び出して、ユニットテストにインポートします。以下に例を示します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:67
msgid "Importing and using shared code"
msgstr "共有コードのインポートおよび使用"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:69
msgid "Use shared code whenever possible - don't reinvent the wheel. Ansible offers the ``AnsibleModule`` common Python code, plus :ref:`utilities <developing_module_utilities>` for many common use cases and patterns. You can also create documentation fragments for docs that apply to multiple modules."
msgstr "可能な限り共有コードを使用する - wheel を再実装しないでください。Ansible は ``AnsibleModule`` の一般的な Python コードと、多くの一般的なユースケースおよびパターンに使用する :ref:`ユーティリティー <developing_module_utilities>` を提供します。また、複数のモジュールに適用されるドキュメントフラグメントを作成することもできます。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:70
msgid "Import ``ansible.module_utils`` code in the same place as you import other libraries."
msgstr "他のライブラリーをインポートする場所と同じ場所に ``ansible.module_utils`` コードをインポートします。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:71
msgid "Do NOT use wildcards (*) for importing other python modules; instead, list the function(s) you are importing (for example, ``from some.other_python_module.basic import otherFunction``)."
msgstr "他の python モジュールのインポートにはワイルドカード (*) を使用しないでください。代わりに、インポートする関数を一覧表示してください (例: ``from some.other_python_module.basic import otherFunction``。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:72
msgid "Import custom packages in ``try``/``except``, capture any import errors, and handle them with ``fail_json()`` in ``main()``. For example:"
msgstr "``try``/``except`` でカスタムパッケージをインポートし、インポートエラーを捕捉し、``main()`` の ``fail_json()`` で処理します。以下は例となります。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:89
msgid "Then in ``main()``, just after the argspec, do"
msgstr "次に ``main()`` で、argspec の直後に以下を実行します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:98
msgid "And document the dependency in the ``requirements`` section of your module's :ref:`documentation_block`."
msgstr "また、依存関係をモジュールの :ref:`documentation_block` の ``requirements`` セクションで記述します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:103
msgid "Handling module failures"
msgstr "モジュール障害の処理"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:105
msgid "When your module fails, help users understand what went wrong. If you are using the ``AnsibleModule`` common Python code, the ``failed`` element will be included for you automatically when you call ``fail_json``. For polite module failure behavior:"
msgstr "モジュールが失敗すると、ユーザーは問題を理解するのに役立ちます。一般的な Python コード ``AnsibleModule`` を使用している場合は、``fail_json`` の呼び出し時に自動的に ``failed`` 要素が含まれます。polite モジュールの失敗動作には、以下を行います。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:107
msgid "Include a key of ``failed`` along with a string explanation in ``msg``. If you don't do this, Ansible will use standard return codes: 0=success and non-zero=failure."
msgstr "``msg`` の文字列の説明と共に ``failed`` のキーが含まれるようにします。これを行わないと、Ansible は標準の戻りコード 0=success および non-zero=failure を使用します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:108
msgid "Don't raise a traceback (stacktrace). Ansible can deal with stacktraces and automatically converts anything unparsable into a failed result, but raising a stacktrace on module failure is not user-friendly."
msgstr "トレースバック (スタックトレース) は発生させません。Ansible はスタックトレースを扱うことができ、解析できないものは自動的に失敗した結果に変換しますが、モジュールの失敗時にスタックトレースを発生させるのはユーザーフレンドリーではありません。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:109
msgid "Do not use ``sys.exit()``. Use ``fail_json()`` from the module object."
msgstr "``sys.exit()`` は使用しないでください。モジュールオブジェクトの ``fail_json()`` を使用してください。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:112
msgid "Handling exceptions (bugs) gracefully"
msgstr "例外 (バグ) を正常に処理"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:114
msgid "Validate upfront--fail fast and return useful and clear error messages."
msgstr "前もって検証します。早めに失敗し、有用で明確なエラーメッセージを返します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:115
msgid "Use defensive programming--use a simple design for your module, handle errors gracefully, and avoid direct stacktraces."
msgstr "防御的なプログラミングを使用します。モジュールにはシンプルなデザインを使用し、エラーを適切に処理し、直接のスタックトレースを回避します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:116
msgid "Fail predictably--if we must fail, do it in a way that is the most expected. Either mimic the underlying tool or the general way the system works."
msgstr "予測可能な方法で失敗させます。失敗がどうしても避けられない場合は、最も期待される方法で失敗します。基礎となるツール、またはシステムの一般的な動作方法を模倣します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:117
msgid "Give out a useful message on what you were doing and add exception messages to that."
msgstr "実行内容に関する有用なメッセージを表示して、それに例外メッセージを追加します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:118
msgid "Avoid catchall exceptions, they are not very useful unless the underlying API gives very good error messages pertaining the attempted action."
msgstr "キャッチオール例外は使用しないでください。基になる API が試行されたアクションに関して非常に優れたエラーメッセージがない限り、これらの例外はほとんど役に立ちません。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:123
msgid "Creating correct and informative module output"
msgstr "正確で有益なモジュール出力を作成"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:125
msgid "Modules must output valid JSON only. Follow these guidelines for creating correct, useful module output:"
msgstr "モジュールは有効な JSON のみを出力しなければなりません。正確で有用なモジュール出力を作成するには、以下のガイドラインに従ってください。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:127
msgid "Make your top-level return type a hash (dictionary)."
msgstr "最上位レベルの戻り値の型をハッシュ (ディレクトリー) にします。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:128
msgid "Nest complex return values within the top-level hash."
msgstr "複雑な戻り値をトップレベルのハッシュ内に入れ子にします。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:129
msgid "Incorporate any lists or simple scalar values within the top-level return hash."
msgstr "最上位レベルの戻り値ハッシュ内にリストや単純なスカラー値を組み込みます。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:130
msgid "Do not send module output to standard error, because the system will merge standard out with standard error and prevent the JSON from parsing."
msgstr "モジュールの出力を標準エラーに送らないでください。システムが標準エラーと標準出力をマージし、JSON の解析を妨げるためです。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:131
msgid "Capture standard error and return it as a variable in the JSON on standard out. This is how the command module is implemented."
msgstr "標準エラーを取得し、標準出力の JSON で変数として返します。これは、コマンドモジュールの実装方法です。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:132
msgid "Never do ``print(\"some status message\")`` in a module, because it will not produce valid JSON output."
msgstr "有効な JSON 出力が生成されないため、モジュールで ``print(\"some status message\")`` を実行しないでください。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:133
msgid "Always return useful data, even when there is no change."
msgstr "変更がない場合でも、有用なデータを常に返します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:134
msgid "Be consistent about returns (some modules are too random), unless it is detrimental to the state/action."
msgstr "状態/アクションに有害でない限り、戻り値は一貫したものにしてください (モジュールによっては非常に乱雑なものもあります)。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:135
msgid "Make returns reusable--most of the time you don't want to read it, but you do want to process it and re-purpose it."
msgstr "戻り値は再利用可能なものにします。ほとんどの場合は読むことはありませんが、処理して再利用できるものにします。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:136
msgid "Return diff if in diff mode. This is not required for all modules, as it won't make sense for certain ones, but please include it when applicable."
msgstr "diff モードの場合は diff を返します。これは、特定のモジュールでは意味をなさないため、すべてのモジュールに必要なわけではありませんが、該当する場合には使用してください。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:137
msgid "Enable your return values to be serialized as JSON with Python's standard `JSON encoder and decoder <https://docs.python.org/3/library/json.html>`_ library. Basic python types (strings, int, dicts, lists, and so on) are serializable."
msgstr "Python の標準の `JSON エンコーダーおよびデコーダー <https://docs.python.org/3/library/json.html>`_ ライブラリーで、戻り値を JSON としてシリアライズできるようにします。基本的な python タイプ (文字列、int、ディクショナリー、リストなど) はシリアライズ可能です。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:138
msgid "Do not return an object using exit_json(). Instead, convert the fields you need from the object into the fields of a dictionary and return the dictionary."
msgstr "exit_json() を使用してオブジェクトを返さないでください。代わりに、オブジェクトの必要なフィールドをディクショナリーのフィールドに変換して返します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:139
msgid "Results from many hosts will be aggregated at once, so your module should return only relevant output. Returning the entire contents of a log file is generally bad form."
msgstr "多数のホストからの結果が一度に集約されるため、モジュールは関連する出力だけを返すべきです。ログファイルの内容全体を返すのは、一般的には悪い形式です。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:141
msgid "If a module returns stderr or otherwise fails to produce valid JSON, the actual output will still be shown in Ansible, but the command will not succeed."
msgstr "モジュールが stderr を返すか、有効な JSON の生成に失敗した場合でも、実際の出力は Ansible に表示されますが、コマンドは成功しません。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:146
msgid "Following Ansible conventions"
msgstr "Ansible の規則に準拠"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:148
msgid "Ansible conventions offer a predictable user interface across all modules, playbooks, and roles. To follow Ansible conventions in your module development:"
msgstr "Ansible の規則は、すべてのモジュール、Playbook、ロールに渡って予測可能なユーザーインターフェースを提供します。モジュール開発において Ansible の規則に従うには、以下を行います。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:150
msgid "Use consistent names across modules (yes, we have many legacy deviations - don't make the problem worse!)."
msgstr "モジュール間で一貫性のある名前を使用します (レガシーとの相違が多数あるため、問題を悪化させないようにしましょう)。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:151
msgid "Use consistent options (arguments) within your module(s)."
msgstr "モジュール内で一貫したオプション (引数) を使用します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:152
msgid "Do not use 'message' or 'syslog_facility' as an option name, because this is used internally by Ansible."
msgstr "これは Ansible によって内部で使用されるため、オプション名には「message」または「syslog_facility」を使用しないでください。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:153
msgid "Normalize options with other modules - if Ansible and the API your module connects to use different names for the same option, add aliases to your options so the user can choose which names to use in tasks and playbooks."
msgstr "他のモジュールでオプションを正規化します。Ansible と、モジュールが接続する API が同じオプションに異なる名前を使用している場合は、オプションにエイリアスを追加して、ユーザーがタスクおよび Playbook で使用する名前を選択できるようにします。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:154
msgid "Return facts from ``*_facts`` modules in the ``ansible_facts`` field of the :ref:`result dictionary<common_return_values>` so other modules can access them."
msgstr "他のモジュールがそれらにアクセスできるように、:ref:`結果ディクショナリー<common_return_values>` の ``ansible_facts`` フィールドの ``*_facts`` モジュールからファクトを返します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:155
msgid "Implement ``check_mode`` in all ``*_info`` and ``*_facts`` modules. Playbooks which conditionalize based on fact information will only conditionalize correctly in ``check_mode`` if the facts are returned in ``check_mode``. Usually you can add ``supports_check_mode=True`` when instantiating ``AnsibleModule``."
msgstr "すべての ``*_info`` および ``*_facts`` モジュールに ``check_mode`` を実装します。ファクト情報をもとに条件付けされる Playbook は、ファクトが ``check_mode`` で返される場合にのみ ``check_mode`` で条件化されます。 通常は、``AnsibleModule`` をインスタンス化する時に ``supports_check_mode=True`` を追加することができます。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:156
msgid "Use module-specific environment variables. For example, if you use the helpers in ``module_utils.api`` for basic authentication with ``module_utils.urls.fetch_url()`` and you fall back on environment variables for default values, use a module-specific environment variable like :code:`API_<MODULENAME>_USERNAME` to avoid conflicts between modules."
msgstr "モジュール固有の環境変数を使用します。たとえば、``module_utils.urls.fetch_url()`` での基本的な認証に ``module_utils.api`` のヘルパーを使用し、デフォルト値を環境変数に依存している場合は、モジュール間の競合を回避するために :code:`API_<MODULENAME>_USERNAME` のようなモジュール固有の環境変数を使用します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:157
msgid "Keep module options simple and focused - if you're loading a lot of choices/states on an existing option, consider adding a new, simple option instead."
msgstr "モジュールのオプションはシンプルで焦点を絞ったものにします。既存のオプションに多くの選択肢や状態を読み込んでいる場合は、代わりに新しいシンプルなオプションを追加することを検討してください。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:158
msgid "Keep options small when possible. Passing a large data structure to an option might save us a few tasks, but it adds a complex requirement that we cannot easily validate before passing on to the module."
msgstr "可能な場合はオプションのサイズを小さくします。大きなデータ構造をオプションに渡すと、いくつかの作業が省けるかもしれませんが、モジュールに渡す前に簡単に検証できない複雑な要件が追加されてしまいます。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:159
msgid "If you want to pass complex data to an option, write an expert module that allows this, along with several smaller modules that provide a more 'atomic' operation against the underlying APIs and services. Complex operations require complex data. Let the user choose whether to reflect that complexity in tasks and plays or in  vars files."
msgstr "複雑なデータをオプションに渡したいのであれば、それを可能にするエキスパートモジュールと、基礎となる API やサービスに対してより「アトミックな」操作を提供するいくつかの小さなモジュールを作成します。複雑な操作には複雑なデータが必要です。その複雑さをタスクやプレイに反映させるか、vars ファイルに反映させるかをユーザが選択できるようにします。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:160
msgid "Implement declarative operations (not CRUD) so the user can ignore existing state and focus on final state. For example, use ``started/stopped``, ``present/absent``."
msgstr "ユーザーが既存の状態を無視して最終的な状態に集中できるように、(CRUDではなく) 宣言的な操作を実装します。たとえば、``started/stopped``、``present/absent`` を使用します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:161
msgid "Strive for a consistent final state (aka idempotency). If running your module twice in a row against the same system would result in two different states, see if you can redesign or rewrite to achieve consistent final state. If you can't, document the behavior and the reasons for it."
msgstr "最終状態が一貫したもの (別名、冪等性) になるようにします。同じシステムに対してモジュールを連続して 2 回実行すると 2 つの異なる状態になってしまう場合は、最終的な状態が一貫しているかどうかを再設計または書き換えてみてください。できない場合は、動作とその理由を記載してください。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:162
msgid "Provide consistent return values within the standard Ansible return structure, even if NA/None are used for keys normally returned under other options."
msgstr "通常は他のオプションで返されるキーに NA/None が使用されている場合でも、標準の Ansible の戻り値構造内で一貫性のある戻り値を提供します。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:166
msgid "Module Security"
msgstr "モジュールのセキュリティー"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:168
msgid "Avoid passing user input from the shell."
msgstr "シェルからユーザー入力を渡さないようにします。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:169
msgid "Always check return codes."
msgstr "常に戻りコードを確認してください。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:170
msgid "You must always use ``module.run_command``, not ``subprocess`` or ``Popen`` or ``os.system``."
msgstr "``subprocess``、``Popen``、または ``os.system`` ではなく、常に ``module.run_command`` を使用する必要があります。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:171
msgid "Avoid using the shell unless absolutely necessary."
msgstr "絶対に必要な場合を除き、シェルは使用しないでください。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:172
msgid "If you must use the shell, you must pass ``use_unsafe_shell=True`` to ``module.run_command``."
msgstr "シェルを使用する必要がある場合は、``use_unsafe_shell=True`` を ``module.run_command`` に渡す必要があります。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:173
msgid "If any variables in your module can come from user input with ``use_unsafe_shell=True``, you must wrap them with ``pipes.quote(x)``."
msgstr "モジュールの変数が ``use_unsafe_shell=True`` を使用してユーザー入力から送られる場合は、``pipes.quote(x)`` でラップする必要があります。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:174
msgid "When fetching URLs, use ``fetch_url`` or ``open_url`` from ``ansible.module_utils.urls``. Do not use ``urllib2``, which does not natively verify TLS certificates and so is insecure for https."
msgstr "URL を取得する際には、``ansible.module_utils.urls`` から ``fetch_url`` または ``open_url`` を使用してください。``urllib2`` を使用しないでください。TLS 証明書をネイティブで検証しないため、https では安全ではありません。"

#: ../../rst/dev_guide/developing_modules_best_practices.rst:175
msgid "Sensitive values marked with ``no_log=True`` will automatically have that value stripped from module return values. If your module could return these sensitive values as part of a dictionary key name, you should call the ``ansible.module_utils.basic.sanitize_keys()`` function to strip the values from the keys. See the ``uri`` module for an example."
msgstr "``no_log=True`` のマークが付いた機密値は自動的に、モジュールの戻り値から取り除かれます。モジュールがこれらの機密値をディクショナリーキー名の一部として返すことができる場合は、``ansible.module_utils.basic.sanitize_keys()`` 関数を呼び出してキーから値を取り除く必要があります。たとえば、``uri`` モジュールを参照してください。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:6
msgid "Contributing your module to an existing Ansible collection"
msgstr "既存の Ansible コレクションへのモジュールの貢献"

#: ../../rst/dev_guide/developing_modules_checklist.rst:8
msgid "If you want to contribute a module to an existing collection, you must meet the community's objective and subjective requirements. Please read the details below, and also review our :ref:`tips for module development <developing_modules_best_practices>`."
msgstr "既存のコレクションにモジュールを提供する場合は、コミュニティーの目的の要件と主体的な要件を満たす必要があります。以下の詳細を読み、「:ref:`モジュール開発のヒント <developing_modules_best_practices>`」も確認してください。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:10
msgid "Modules accepted into certain collections are included in every Ansible release on PyPI. However, contributing to one of these collections is not the only way to distribute a module - you can :ref:`create your own collection <developing_collections>`, embed modules in roles on Galaxy or simply share copies of your module code for :ref:`local use <developing_locally>`."
msgstr "特定のコレクションで許可されるモジュールは、PyPI のすべての Ansible リリースに含まれます。ただし、これらのコレクションのいずれかに貢献することが、モジュールを配布する唯一の方法ではありません。:ref:`独自のコレクションの作成 <developing_collections>` は、Galaxy のロールにモジュールコードのコピーを埋め込んだり、:ref:`ローカルでの使用 <developing_locally>` 用にモジュールコードのコピーを共有することもできます。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:13
msgid "Contributing modules: objective requirements"
msgstr "モジュールの貢献: 目的要件"

#: ../../rst/dev_guide/developing_modules_checklist.rst:15
msgid "To contribute a module to most Ansible collections, you must:"
msgstr "モジュールをほとんどの Ansible コレクションに提供するには、以下を行う必要があります。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:17
msgid "write your module in either Python or Powershell for Windows"
msgstr "Windows 用の Python または Powershell のいずれかでモジュールを書き込みます。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:18
msgid "use the ``AnsibleModule`` common code"
msgstr "``AnsibleModule`` 共通コードを使用します。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:19
msgid "support Python 2.6 and Python 3.5 - if your module cannot support Python 2.6, explain the required minimum Python version and rationale in the requirements section in ``DOCUMENTATION``"
msgstr "Python 2.6 および Python 3.5 をサポートします。モジュールが Python 2.6 をサポートできない場合は、``DOCUMENTATION`` の要件セクションで、最低限必要な Python バージョンと根拠を説明します。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:20
msgid "use proper :ref:`Python 3 syntax <developing_python_3>`"
msgstr "適切な :ref:`Python 3 構文 <developing_python_3>` を使用します。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:21
msgid "follow `PEP 8 <https://www.python.org/dev/peps/pep-0008/>`_ Python style conventions - see :ref:`testing_pep8` for more information"
msgstr "`PEP 8 <https://www.python.org/dev/peps/pep-0008/>`_ Python スタイルの規則に従います。詳細は「:ref:`testing_pep8`」を参照してください。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:22
msgid "license your module under the GPL license (GPLv3 or later)"
msgstr "GPL ライセンス (GPLv3 以降) でモジュールにライセンスを付与します。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:23
msgid "understand the :ref:`license agreement <contributor_license_agreement>`, which applies to all contributions"
msgstr "すべての貢献に適用される :ref:`ライセンス合意 <contributor_license_agreement>` を理解します。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:24
msgid "conform to Ansible's :ref:`formatting and documentation <developing_modules_documenting>` standards"
msgstr "Ansible の :ref:`フォーマットおよびドキュメント <developing_modules_documenting>` の標準規格に準拠しています。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:25
msgid "include comprehensive :ref:`tests <developing_testing>` for your module"
msgstr "モジュールに包括的な :ref:`テスト <developing_testing>` を含めます。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:26
msgid "minimize module dependencies"
msgstr "モジュール依存関係を最小限に抑えます。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:27
msgid "support :ref:`check_mode <check_mode_dry>` if possible"
msgstr "可能な場合は :ref:`check_mode <check_mode_dry>` をサポートします。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:28
msgid "ensure your code is readable"
msgstr "コードが読み取り可能であることを確認します。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:29
msgid "if a module is named ``<something>_facts``, it should be because its main purpose is returning ``ansible_facts``. Do not name modules that do not do this with ``_facts``. Only use ``ansible_facts`` for information that is specific to the host machine, for example network interfaces and their configuration, which operating system and which programs are installed."
msgstr "モジュールの名前が ``<something>_facts`` なのは、``ansible_facts`` を返すことが主な目的だからです。これは、``_facts`` でこれを行わないモジュールに名前を付けないでください。ネットワークインターフェースやその設定や、オペレーティングシステムやインストールされているプログラムなど、ホストマシンに固有の情報には ``ansible_facts`` のみを使用してください。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:30
msgid "Modules that query/return general information (and not ``ansible_facts``) should be named ``_info``. General information is non-host specific information, for example information on online/cloud services (you can access different accounts for the same online service from the same host), or information on VMs and containers accessible from the machine."
msgstr "一般情報をクエリー/返送するモジュールは (``ansible_facts`` ではなく) ``_info`` という名前にする必要があります。一般情報とは、ホスト固有ではない情報、たとえば、オンライン/クラウドサービスに関する情報 (同じホストから同じオンラインサービスの異なるアカウントにアクセスできます)、または、マシンからアクセス可能な仮想マシンおよびコンテナーに関する情報になります。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:32
msgid "Additional requirements may apply for certain collections. Review the individual collection repositories for more information."
msgstr "追加の要件は、特定のコレクションに適用される可能性があります。詳細は、個別のコレクションリポジトリーを参照してください。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:34
msgid "Please make sure your module meets these requirements before you submit your PR/proposal. If you have questions, reach out via the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat <https://libera.chat>`_) or the `Ansible development mailing list <https://groups.google.com/group/ansible-devel>`_."
msgstr "PR/提案を送信する前に、お使いのモジュールがこれらの要件を満たしていることを確認してください。ご質問がある場合は、``#ansible-devel``チャットチャンネル（ansible.imでMatrixを使用、もしくは`irc.libera.chat <https://libera.chat>`でIRCを使用）または `Ansible development mailing list <https://groups.google.com/group/ansible-devel>` までお問い合わせください。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:37
msgid "Contributing to Ansible: subjective requirements"
msgstr "Ansible への貢献: 主観的な要件"

#: ../../rst/dev_guide/developing_modules_checklist.rst:39
msgid "If your module meets these objective requirements, collection maintainers will review your code to see if they think it's clear, concise, secure, and maintainable. They will consider whether your module provides a good user experience, helpful error messages, reasonable defaults, and more. This process is subjective, with no exact standards for acceptance. For the best chance of getting your module accepted, follow our :ref:`tips for module development <developing_modules_best_practices>`."
msgstr "モジュールがこれらの目的の要件を満たす場合は、コレクションのメンテナーが、明確、簡潔、安全であり、維持が可能であると考えるコードを確認します。モジュールが優れたユーザーエクスペリエンスを提供し、有用なエラーメッセージ、有益なデフォルトなどを提供するかどうかを考慮します。このプロセスは主観的で、正確な標準はありません。モジュールが受け入れられる可能性を最大限に高めるには、「:ref:`モジュール開発のヒント <developing_modules_best_practices>`」に従ってください。"

#: ../../rst/dev_guide/developing_modules_checklist.rst:42
msgid "Other checklists"
msgstr "その他のチェックリスト"

#: ../../rst/dev_guide/developing_modules_checklist.rst:44
msgid ":ref:`Tips for module development <developing_modules_best_practices>`."
msgstr ":ref:`モジュール開発のヒント <developing_modules_best_practices>`"

#: ../../rst/dev_guide/developing_modules_checklist.rst:45
msgid ":ref:`Windows development checklist <developing_modules_general_windows>`."
msgstr ":ref:`Windows 開発チェックリスト <developing_modules_general_windows>`"

#: ../../rst/dev_guide/developing_modules_documenting.rst:6
msgid "Module format and documentation"
msgstr "モジュールの形式およびドキュメント"

#: ../../rst/dev_guide/developing_modules_documenting.rst:8
msgid "If you want to contribute your module to most Ansible collections, you must write your module in Python and follow the standard format described below. (Unless you're writing a Windows module, in which case the :ref:`Windows guidelines <developing_modules_general_windows>` apply.) In addition to following this format, you should review our :ref:`submission checklist <developing_modules_checklist>`, :ref:`programming tips <developing_modules_best_practices>`, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility <developing_python_3>`, as well as information about :ref:`testing <developing_testing>` before you open a pull request."
msgstr "モジュールをほとんどの Ansible コレクションに貢献する場合は、Python でモジュールを作成して、その標準形式に従う必要があります。(Windows モジュールを作成したことがない場合。この場合は、:ref:`Windows ガイドライン <developing_modules_general_windows>` が適用されます)。この形式に従うことに加え、プル要求を作成する前に、:ref:`提出のチェックリスト <developing_modules_checklist>`、:ref:`プログラムのヒント <developing_modules_best_practices>`、:ref:`Python 2 および Python 3 互換性の維持のストラテジー <developing_python_3>` と、:ref:`テスト <developing_testing>` に関する情報をお読みください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:10
msgid "Every Ansible module written in Python must begin with seven standard sections in a particular order, followed by the code. The sections in order are:"
msgstr "Python で書かれたすべての Ansible モジュールは、特定の順序で 7 つの標準セクションから始まり、その後にコードが続きます。セクションの順番は以下のとおりです。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:16
msgid "Why don't the imports go first?"
msgstr "最初にインポートが行われないのはなぜですか。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:18
msgid "Keen Python programmers may notice that contrary to PEP 8's advice we don't put ``imports`` at the top of the file. This is because the ``DOCUMENTATION`` through ``RETURN`` sections are not used by the module code itself; they are essentially extra docstrings for the file. The imports are placed after these special variables for the same reason as PEP 8 puts the imports after the introductory comments and docstrings. This keeps the active parts of the code together and the pieces which are purely informational apart. The decision to exclude E402 is based on readability (which is what PEP 8 is about). Documentation strings in a module are much more similar to module level docstrings, than code, and are never utilized by the module itself. Placing the imports below this documentation and closer to the code, consolidates and groups all related code in a congruent manner to improve readability, debugging and understanding."
msgstr "熱心な Python プログラマーは、PEP 8 のアドバイスに反して、ファイルの冒頭に ``imports`` を置いていないことに気づくかもしれません。これは、``RETURN`` までの ``DOCUMENTATION`` セクションはモジュールコード自体で使用されておらず、基本的にファイルに追加のドキュメント文字列を使用するためです。インポートは、PEP 8 と同じ理由でこれらの特別な変数の後に置かれ、紹介のコメントとドキュメント文字列の後にインポートを追加します。これにより、コードの活動的な部分が一緒になり、純粋に情報を提供する部分が分離されます。E402 を除外する意思決定は (PEP 8 の目的である) 可読性に基づいています。モジュール内のドキュメント文字列は、コードよりも、モジュールレベルのドキュメント文字列によく似ており、モジュール自体が利用することはありません。インポートを、このドキュメントの下の、よりコードに近いところに置くことで、関連するすべてのコードを統合してグループ化し、可読性、デバッグ、理解を向上させます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:20
msgid "**Copy old modules with care!**"
msgstr "**古いモジュールは注意してコピーしてください。**"

#: ../../rst/dev_guide/developing_modules_documenting.rst:22
msgid "Some older Ansible modules have ``imports`` at the bottom of the file, ``Copyright`` notices with the full GPL prefix, and/or ``DOCUMENTATION`` fields in the wrong order. These are legacy files that need updating - do not copy them into new modules. Over time we are updating and correcting older modules. Please follow the guidelines on this page!"
msgstr "一部の古い Ansible モジュールでは、ファイルの下部に ``imports`` があるため、``Copyright`` は完全な GPL プレフィックス、または ``DOCUMENTATION`` フィールドを間違った順序で持つことに注意してください。これらは更新が必要なレガシーファイルです。新しいモジュールにコピーしないでください。時間の経過とともに、古いモジュールを更新および修正しています。このページにはガイドラインに従うようにしてください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:27
msgid "Python shebang & UTF-8 coding"
msgstr "Python シバンおよび UTF-8 コーディング"

#: ../../rst/dev_guide/developing_modules_documenting.rst:29
msgid "Begin your Ansible module with ``#!/usr/bin/python`` - this \"shebang\" allows ``ansible_python_interpreter`` to work. Follow the shebang immediately with ``# -*- coding: utf-8 -*-`` to clarify that the file is UTF-8 encoded."
msgstr "``#!/usr/bin/python`` で Ansible モジュールを開始します (この「シバン」では ``ansible_python_interpreter`` が機能します)。ファイルが UTF-8 でエンコードされていることを明確にするために、シバンの直後に ``# -*- coding: utf-8 -*-`` を使用します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:34
msgid "Copyright and license"
msgstr "著作権およびライセンス"

#: ../../rst/dev_guide/developing_modules_documenting.rst:36
msgid "After the shebang and UTF-8 coding, add a `copyright line <https://www.linuxfoundation.org/blog/copyright-notices-in-open-source-software-projects/>`_ with the original copyright holder and a license declaration. The license declaration should be ONLY one line, not the full GPL prefix.:"
msgstr "シバンおよび UTF-8 コーディングの後に、元の著作権所有者およびライセンス宣言を含む `copyright line <https://www.linuxfoundation.org/blog/copyright-notices-in-open-source-software-projects/>`_ を追加します。ライセンス宣言は、完全な GPL プレフィックスではなく、1 行のみにする必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:46
msgid "Additions to the module (for instance, rewrites) are not permitted to add additional copyright lines other than the default copyright statement if missing:"
msgstr "モジュールを追加するときに、以下が欠けている場合に、デフォルトの著作権ステートメント以外に、著作権の行を追加できません。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:52
msgid "Any legal review will include the source control history, so an exhaustive copyright header is not necessary. Please do not include a copyright year. If the existing copyright statement includes a year, do not edit the existing copyright year. Any existing copyright header should not be modified without permission from the copyright author."
msgstr "法的レビューにはソース管理履歴が含まれるため、完全な著作権ヘッダーは必要ありません。著作権の年は含めないでください。既存の著作権ステートメントに年が含まれている場合は、既存の著作権の年を編集しないでください。既存の著作権ヘッダーは、著作権者の許可なしに変更しないでください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:58
msgid "ANSIBLE_METADATA block"
msgstr "ANSIBLE_METADATA ブロック"

#: ../../rst/dev_guide/developing_modules_documenting.rst:60
msgid "Since we moved to collections we have deprecated the METADATA functionality, it is no longer required for modules, but it will not break anything if present."
msgstr "コレクションに移行しても METADATA 機能は非推奨になり、モジュールには必要なくなりましたが、存在しても何も破損しません。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:66
msgid "DOCUMENTATION block"
msgstr "DOCUMENTATION ブロック"

#: ../../rst/dev_guide/developing_modules_documenting.rst:68
msgid "After the shebang, the UTF-8 coding, the copyright line, and the license section comes the ``DOCUMENTATION`` block. Ansible's online module documentation is generated from the ``DOCUMENTATION`` blocks in each module's source code. The ``DOCUMENTATION`` block must be valid YAML. You may find it easier to start writing your ``DOCUMENTATION`` string in an :ref:`editor with YAML syntax highlighting <other_tools_and_programs>` before you include it in your Python file. You can start by copying our `example documentation string <https://github.com/ansible/ansible/blob/devel/examples/DOCUMENTATION.yml>`_ into your module file and modifying it. If you run into syntax issues in your YAML, you can validate it on the `YAML Lint <http://www.yamllint.com/>`_ website."
msgstr "shebang、UTF-8 コーディング、著作権行、ライセンスセクションの後には、``DOCUMENTATION`` ブロックがあります。Ansible のオンラインモジュールドキュメントは、各モジュールのソースコード内の ``DOCUMENTATION`` ブロックから生成されます。``DOCUMENTATION`` ブロックは有効な YAML でなければなりません。Python ファイルに含める前に、``DOCUMENTATION`` の文字列を :ref:`YAML 構文の強調表示を使用したエディター <other_tools_and_programs>` に書き始めた方が簡単だと思うかもしれません。提供している `サンプルのドキュメントの文字列 <https://github.com/ansible/ansible/blob/devel/examples/DOCUMENTATION.yml>`_ を自身のモジュールファイルにコピーして、それを修正することから始めることができます。YAML の構文に問題がある場合は、`YAML Lint <http://www.yamllint.com/>`_ の Web サイトで検証することができます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:76
msgid "Module documentation should briefly and accurately define what each module and option does, and how it works with others in the underlying system. Documentation should be written for broad audience--readable both by experts and non-experts."
msgstr "モジュールのドキュメントでは、各モジュールとオプションの動作について簡単かつ正確に定義し、基礎となるシステムで他のモジュールとどのように連携するかを説明します。ドキュメントは、専門家と非専門家の両方が読むことができるように、幅広い読者に向けて作成する必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:71
msgid "Descriptions should always start with a capital letter and end with a full stop. Consistency always helps."
msgstr "説明は常に大文字で始め、完全に終了する必要があります。一貫性は常に役立ちます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:72
msgid "Verify that arguments in doc and module spec dict are identical."
msgstr "ドキュメントの引数と、モジュール仕様のディクショナリーが同じであることを確認します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:73
msgid "For password / secret arguments ``no_log=True`` should be set."
msgstr "パスワード/シークレット引数 ``no_log=True`` を設定する必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:74
msgid "For arguments that seem to contain sensitive information but **do not** contain secrets, such as \"password_length\", set ``no_log=False`` to disable the warning message."
msgstr "機密情報が含まれているように見えても「password_length」などのシークレットが **含まれていない** ように表示される引数には、``no_log=False`` を設定して警告メッセージを無効にします。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:75
#: ../../rst/dev_guide/developing_modules_documenting.rst:143
msgid "If an option is only sometimes required, describe the conditions. For example, \"Required when I(state=present).\""
msgstr "オプションのみが必要な場合は、条件を記述してください。たとえば、「Required when I(state=present)」です。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:76
msgid "If your module allows ``check_mode``, reflect this fact in the documentation."
msgstr "モジュールで ``check_mode`` が許可されている場合は、これをドキュメントに反映させます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:78
msgid "To create clear, concise, consistent, and useful documentation, follow the :ref:`style guide <style_guide>`."
msgstr "明確かつ簡潔で一貫性があり、便利なドキュメントは :ref:`スタイルガイド <style_guide>` に従います。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:80
msgid "Each documentation field is described below. Before committing your module documentation, please test it at the command line and as HTML:"
msgstr "各ドキュメントフィールドの説明は次のとおりです。モジュールのドキュメントをコミットする前に、コマンドラインおよび HTML でテストしてください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:82
msgid "As long as your module file is :ref:`available locally <local_modules>`, you can use ``ansible-doc -t module my_module_name`` to view your module documentation at the command line. Any parsing errors will be obvious - you can view details by adding ``-vvv`` to the command."
msgstr "モジュールファイルが :ref:`ローカルで利用可能 <local_modules>` な場合に限り、``ansible-doc -t module my_module_name`` を使用して、コマンドラインでモジュールのドキュメントを表示します。構文解析エラーは明確になります。コマンドに ``-vvv`` を追加すると、詳細を表示できます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:83
msgid "You should also :ref:`test the HTML output <testing_module_documentation>` of your module documentation."
msgstr "モジュールのドキュメントにおける :ref:`HTML 出力のテスト <testing_module_documentation>` も必要です。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:86
msgid "Documentation fields"
msgstr "ドキュメントフィールド"

#: ../../rst/dev_guide/developing_modules_documenting.rst:88
msgid "All fields in the ``DOCUMENTATION`` block are lower-case. All fields are required unless specified otherwise:"
msgstr "``DOCUMENTATION`` ブロックのフィールドはすべて小文字になります。特に指定がない場合は、すべてのフィールドが必要になります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:92
msgid "The name of the module."
msgstr "モジュールの名前。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:93
msgid "Must be the same as the filename, without the ``.py`` extension."
msgstr "ファイル名と同じ (``.py`` 拡張子なし) である必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "short_description"
msgstr "short_description"

#: ../../rst/dev_guide/developing_modules_documenting.rst:97
msgid "A short description which is displayed on the :ref:`list_of_collections` page and ``ansible-doc -l``."
msgstr ":ref:`list_of_collections` ページと ``ansible-doc -l`` に表示される簡単な説明です。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:98
msgid "The ``short_description`` is displayed by ``ansible-doc -l`` without any category grouping, so it needs enough detail to explain the module's purpose without the context of the directory structure in which it lives."
msgstr "``short_description`` は、カテゴリーをグループ化せずに、``ansible-doc -l`` によって表示されます。そのため、モジュールが存在するディレクトリー構造のコンテキストなしでモジュールの目的を説明するのに十分な詳細が必要です。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:100
msgid "Unlike ``description:``, ``short_description`` should not have a trailing period/full stop."
msgstr "``description:`` とは異なり、``short_description`` のピリオド (文末) は設定しないでください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "description"
msgstr "description"

#: ../../rst/dev_guide/developing_modules_documenting.rst:104
msgid "A detailed description (generally two or more sentences)."
msgstr "詳細な説明 (通常は 2 文以上)。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:105
msgid "Must be written in full sentences, in other words, with capital letters and periods/full stops."
msgstr "文章の形、つまり冒頭の大文字やピリオド (文末) などを使用して記述する必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:106
msgid "Shouldn't mention the module name."
msgstr "モジュール名について言及すべきではありません。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:107
msgid "Make use of multiple entries rather than using one long paragraph."
msgstr "1 つの長い段落にせず、複数の文章に分けます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:108
msgid "Don't quote complete values unless it is required by YAML."
msgstr "YAML で必要な場合を除き、完全な値を引用符で囲まないでください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "version_added"
msgstr "version_added"

#: ../../rst/dev_guide/developing_modules_documenting.rst:112
msgid "The version of Ansible when the module was added."
msgstr "モジュールが追加された Ansible のバージョン。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:113
msgid "This is a string, and not a float, for example, ``version_added: '2.1'``."
msgstr "これは浮動小数点ではなく文字列です (例: ``version_added: '2.1'``)。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:114
msgid "In collections, this must be the collection version the module was added to, not the Ansible version. For example, ``version_added: 1.0.0``."
msgstr "コレクションでは、これは Ansible バージョンではなく、モジュールが追加されたコレクションバージョンでなければなりません (例: ``version_added: 1.0.0``)。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "author"
msgstr "author"

#: ../../rst/dev_guide/developing_modules_documenting.rst:118
msgid "Name of the module author in the form ``First Last (@GitHubID)``."
msgstr "``First Last (@GitHubID)`` 形式のモジュール作成者の名前。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:119
msgid "Use a multi-line list if there is more than one author."
msgstr "作成者が複数になる場合は、複数行のリストを使用します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:120
msgid "Don't use quotes as it should not be required by YAML."
msgstr "YAML では必要ないため、引用符は使用しないでください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "deprecated"
msgstr "deprecated"

#: ../../rst/dev_guide/developing_modules_documenting.rst:124
msgid "Marks modules that will be removed in future releases. See also :ref:`module_lifecycle`."
msgstr "将来のリリースで削除されるモジュールにマークを付けします。「:ref:`module_lifecycle`」も併せて参照してください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "options"
msgstr "options"

#: ../../rst/dev_guide/developing_modules_documenting.rst:128
msgid "Options are often called `parameters` or `arguments`. Because the documentation field is called `options`, we will use that term."
msgstr "オプションは、多くの場合、`パラメーター` または `引数` と呼ばれます。ドキュメントフィールドは `オプション` を呼ばれるため、ここではその用語を使用します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:129
msgid "If the module has no options (for example, it's a ``_facts`` module), all you need is one line: ``options: {}``."
msgstr "モジュールにオプションがない (例: ``_facts`` モジュール) 場合、必要なのは 1 行 (``options: {}``) だけです。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:130
msgid "If your module has options (in other words, accepts arguments), each option should be documented thoroughly. For each module option, include:"
msgstr "モジュールにオプションがある (つまり引数を受け入れる) 場合、各オプションは詳細に文書化される必要があります。各モジュールオプションについて、以下を記載します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "option-name"
msgstr "option-name"

#: ../../rst/dev_guide/developing_modules_documenting.rst:134
msgid "Declarative operation (not CRUD), to focus on the final state, for example `online:`, rather than `is_online:`."
msgstr "(CRUD ではなく) 宣言操作は、「`is_online:`」ではなく、「`online:`」などの最終状態に焦点をあてます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:135
msgid "The name of the option should be consistent with the rest of the module, as well as other modules in the same category."
msgstr "オプションの名前は、そのモジュールの残りの部分、および同じカテゴリーの他のモジュールと一貫性を持たせる必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:136
msgid "When in doubt, look for other modules to find option names that are used for the same purpose, we like to offer consistency to our users."
msgstr "不明な場合は、他のモジュールを探して、同じ目的で使用されているオプション名を見つけてください。ユーザーに一貫性を提供できるようにしています。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:140
msgid "Detailed explanation of what this option does. It should be written in full sentences."
msgstr "このオプションの機能の詳細な説明。これは、完全な文章で記述する必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:141
msgid "The first entry is a description of the option itself; subsequent entries detail its use, dependencies, or format of possible values."
msgstr "最初のエントリーは、オプションそのものの説明です。後続のエントリーは、その使用、依存関係、または使用できる値の形式の詳細を説明します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:142
msgid "Should not list the possible values (that's what ``choices:`` is for, though it should explain what the values do if they aren't obvious)."
msgstr "可能な値を列挙しないでください (``choices:`` はそのためにあります。値が明らかでない場合は、その値が何を示すのかを説明してください)。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:144
msgid "Mutually exclusive options must be documented as the final sentence on each of the options."
msgstr "相互に排他的なオプションは、各オプションの最後の文で文書化する必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:148
msgid "Only needed if ``true``."
msgstr "``true`` の場合にのみ必要です。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:149
msgid "If missing, we assume the option is not required."
msgstr "見つからない場合は、オプションが不要であると仮定します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "default"
msgstr "default"

#: ../../rst/dev_guide/developing_modules_documenting.rst:153
msgid "If ``required`` is false/missing, ``default`` may be specified (assumed 'null' if missing)."
msgstr "``required`` が false もしくは指定されていない場合は、``default`` を指定できます (見つからない場合は「null」と見なされます)。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:154
msgid "Ensure that the default value in the docs matches the default value in the code."
msgstr "ドキュメントのデフォルト値が、コードのデフォルト値と一致していることを確認してください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:155
msgid "The default field must not be listed as part of the description, unless it requires additional information or conditions."
msgstr "追加の情報や条件が必要な場合を除き、デフォルトのフィールドは、説明の一部として記載しないでください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:156
msgid "If the option is a boolean value, you can use any of the boolean values recognized by Ansible: (such as true/false or yes/no).  Choose the one that reads better in the context of the option."
msgstr "オプションがブール値の場合は、Ansible が認識する任意のブール値 (true/false、yes/no など) を使用できます。オプションのコンテキストで読み取りが適切であればこれを選択します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "choices"
msgstr "choices"

#: ../../rst/dev_guide/developing_modules_documenting.rst:161
msgid "List of option values."
msgstr "オプション値のリスト。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:162
msgid "Should be absent if empty."
msgstr "空欄の場合は指定なしになります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "type"
msgstr "type"

#: ../../rst/dev_guide/developing_modules_documenting.rst:166
msgid "Specifies the data type that option accepts, must match the ``argspec``."
msgstr "オプションで使用できるデータ型を指定します。``argspec`` と一致させる必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:167
msgid "If an argument is ``type='bool'``, this field should be set to ``type: bool`` and no ``choices`` should be specified."
msgstr "引数が ``type='bool'`` の場合、このフィールドは ``type: bool`` に設定されます。``choices`` は指定しないでください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:168
msgid "If an argument is ``type='list'``, ``elements`` should be specified."
msgstr "引数が ``type='list'`` の場合は、``elements`` を指定する必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "elements"
msgstr "elements"

#: ../../rst/dev_guide/developing_modules_documenting.rst:172
msgid "Specifies the data type for list elements in case ``type='list'``."
msgstr "``type='list'`` の場合に、リスト要素のデータ型を指定します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "aliases"
msgstr "aliases"

#: ../../rst/dev_guide/developing_modules_documenting.rst:175
msgid "List of optional name aliases."
msgstr "任意の名前エイリアスのリスト。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:176
msgid "Generally not needed."
msgstr "一般的には必要ありません。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:180
msgid "Only needed if this option was extended after initial Ansible release, in other words, this is greater than the top level `version_added` field."
msgstr "このオプションが Ansible の初回リリース後に拡張されている場合にのみ必要です。つまり、これは最上位レベルの `version_added` フィールドよりも大きくなります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:181
msgid "This is a string, and not a float, for example, ``version_added: '2.3'``."
msgstr "これは浮動小数点ではなく文字列です (例: ``version_added: '2.3'``)。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:182
msgid "In collections, this must be the collection version the option was added to, not the Ansible version. For example, ``version_added: 1.0.0``."
msgstr "コレクションでは、これは Ansible バージョンではなく、オプションが追加されたコレクションバージョンでなければなりません (例: ``version_added: 1.0.0``)。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "suboptions"
msgstr "suboptions"

#: ../../rst/dev_guide/developing_modules_documenting.rst:186
msgid "If this option takes a dict or list of dicts, you can define the structure here."
msgstr "このオプションがディクショナリーまたはディクショナリーのリストを取る場合は、ここで構造を定義できます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:187
msgid "See :ref:`ansible_collections.azure.azcollection.azure_rm_securitygroup_module`, :ref:`ansible_collections.azure.azcollection.azure_rm_azurefirewall_module`, and :ref:`ansible_collections.openstack.cloud.baremetal_node_action_module` for examples."
msgstr "例は、「:ref:`ansible_collections.azure.azcollection.azure_rm_securitygroup_module`」、「:ref:`ansible_collections.azure.azcollection.azure_rm_azurefirewall_module`」、および「:ref:`ansible_collections.openstack.cloud.baremetal_node_action_module`」を参照してください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "requirements"
msgstr "requirements"

#: ../../rst/dev_guide/developing_modules_documenting.rst:191
msgid "List of requirements (if applicable)."
msgstr "要件のリスト (該当する場合)。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:192
msgid "Include minimum versions."
msgstr "最小バージョンを指定します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "seealso"
msgstr "seealso"

#: ../../rst/dev_guide/developing_modules_documenting.rst:196
msgid "A list of references to other modules, documentation or Internet resources"
msgstr "その他のモジュール、ドキュメント、またはインターネットリソースへの参照の一覧。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:197
msgid "In Ansible 2.10 and later, references to modules must use  the FQCN or ``ansible.builtin`` for modules in ``ansible-core``."
msgstr "Ansible 2.10 以降では、モジュールへの参照が ``ansible-core`` のモジュールに FQCN または ``ansible.builtin`` を使用する必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:198
msgid "A reference can be one of the following formats:"
msgstr "参照には、以下の形式のいずれかを使用できます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:226
msgid "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."
msgstr "``ref:`` を使用してタイトルと関連付けられていないアンカーにリンクする場合は、リンクが正しく機能するように ref にタイトルを追加する必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:227
msgid "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>``."
msgstr "rST アンカーを使用して ``ref:`` でモジュール以外のプラグインにリンクできますが、プラグインおよびモジュールアンカーはタイトルと関連付けられないため、リンクする際にタイトルを指定する必要があります。たとえば、``ref: namespace.collection.plugin_name lookup plugin  <ansible_collections.namespace.collection.plugin_name_lookup>`` となります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "notes"
msgstr "notes"

#: ../../rst/dev_guide/developing_modules_documenting.rst:232
msgid "Details of any important information that doesn't fit in one of the above sections."
msgstr "上記のセクションのいずれかに該当しない重要な情報の詳細です。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:233
msgid "For example, whether ``check_mode`` is or is not supported."
msgstr "たとえば、``check_mode`` がサポートされるかどうかなどです。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:238
msgid "Linking and other format macros within module documentation"
msgstr "モジュールドキュメント内のリンクおよびその他の形式マクロ"

#: ../../rst/dev_guide/developing_modules_documenting.rst:240
msgid "You can link from your module documentation to other module docs, other resources on docs.ansible.com, and resources elsewhere on the internet with the help of some pre-defined macros. The correct formats for these macros are:"
msgstr "モジュールドキュメントから他のモジュールドキュメント、docs.ansible.com の他のリソース、一部の事前設定マクロでインターネット上の他のリソースにリンクできます。これらのマクロの正しい形式は次のとおりです。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:242
msgid "``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."
msgstr "``L()`` 見出しへのリンク。たとえば、``See L(Ansible Automation Platform,https://www.ansible.com/products/automation-platform).`` となります。Ansible 2.10 以降、Ansible ドキュメントとコレクションのドキュメントの相対リンクには ``L()`` を使用しないでください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:243
msgid "``U()`` for URLs. For example: ``See U(https://www.ansible.com/products/automation-platform) for an overview.``"
msgstr "URL の場合は ``U()``。たとえば、``See U(https://www.ansible.com/products/automation-platform) for an overview.`` となります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:244
msgid "``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."
msgstr "(Ansible 2.10 に含まれる) 見出しと相互参照用 ``R()`` (例: ``See R(Cisco IOS Platform Guide,ios_platform_options)``)。クロス参照に RST アンカーを使用します。詳細は、:ref:`adding_anchors_rst` を参照してください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:245
msgid "``M()`` for module names. For example: ``See also M(ansible.builtin.yum) or M(community.general.apt_rpm)``."
msgstr "``M()`` モジュール名。たとえば ``See also M(ansible.builtin.yum) or M(community.general.apt_rpm)`` になります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:247
msgid "There are also some macros which do not create links but we use them to display certain types of content in a uniform way:"
msgstr "リンクを作成しないものの、そのマクロを使用して、特定のタイプのコンテンツを統一して表示します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:250
msgid "``I()`` for option names. For example: ``Required if I(state=present).``  This is italicized in the documentation."
msgstr "オプション名の場合は ``I()``。たとえば ``Required if I(state=present).`` です。これは、ドキュメントではイタリック体で示されています。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:252
msgid "``C()`` for files, option values, and inline code. For example: ``If not set the environment variable C(ACME_PASSWORD) will be used.`` or ``Use C(var | foo.bar.my_filter) to transform C(var) into the required format.``  This displays with a mono-space font in the documentation."
msgstr "ファイル、オプション値、およびインラインコードの場合は ``C()`` (例 ``If not set the environment variable C(ACME_PASSWORD) will be used.`` または ``Use C(var | foo.bar.my_filter) to transform C(var) into the required format.``)。これは、ドキュメントでは Monospace フォントと表示されます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:253
msgid "``B()`` currently has no standardized usage. It is displayed in boldface in the documentation."
msgstr "現時点で、``B()`` の標準化された使用方法はありません。このドキュメントでは太字で表示されます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:254
msgid "``HORIZONTALLINE`` is used sparingly as a separator in long descriptions. It becomes a horizontal rule (the ``<hr>`` html tag) in the documentation."
msgstr "``HORIZONTALLINE`` は、長い説明では、区切り文字として慎重に使用されており、ドキュメント内の水平ルール (``<hr>`` html タグ) になります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:258
msgid "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."
msgstr "コレクション内のモジュールとドキュメント間のリンクについては、上記のオプションのいずれかを使用することができます。コレクション外のリンクについては、利用可能な場合は ``R()`` を使用します。利用できない場合は、(相対リンクではなく) 完全な URL で ``U()`` または ``L()`` を使用します。モジュールの場合は、例のように、FQCN または ``ansible.builtin`` で ``M()`` を使用します。独自のドキュメントサイトを作成する場合は、`intersphinx 表現 <https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html>`_ を使用して ``R()`` および ``M()`` を正しいリンクに変換する必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:261
msgid "To refer to a group of modules in a collection, use ``R()``.  When a collection is not the right granularity, use ``C(..)``:"
msgstr "コレクション内のモジュールのグループを参照するには、``R()`` を使用します。コレクションが適切な粒度ではない場合は、``C(..)`` を使用します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:263
msgid "``Refer to the R(kubernetes.core collection, plugins_in_kubernetes.core) for information on managing kubernetes clusters.``"
msgstr "``Refer to the R(kubernetes.core collection, plugins_in_kubernetes.core) for information on managing kubernetes clusters.``"

#: ../../rst/dev_guide/developing_modules_documenting.rst:264
msgid "``The C(win_*) modules (spread across several collections) allow you to manage various aspects of windows hosts.``"
msgstr "``The C(win_*) modules (spread across several collections) allow you to manage various aspects of windows hosts.``"

#: ../../rst/dev_guide/developing_modules_documenting.rst:268
msgid "Because it stands out better, use ``seealso`` for general references over the use of notes or adding links to the description."
msgstr "``seealso`` の方が目立つため、一般的な参照にはノートの使用や説明へのリンクよりも、``seealso`` を使用することが推奨されます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:273
msgid "Documentation fragments"
msgstr "ドキュメントフラグメント"

#: ../../rst/dev_guide/developing_modules_documenting.rst:275
msgid "If you are writing multiple related modules, they may share common documentation, such as authentication details, file mode settings, ``notes:`` or ``seealso:`` entries. Rather than duplicate that information in each module's ``DOCUMENTATION`` block, you can save it once as a doc_fragment plugin and use it in each module's documentation. In Ansible, shared documentation fragments are contained in a ``ModuleDocFragment`` class in `lib/ansible/plugins/doc_fragments/ <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/doc_fragments>`_ or the equivalent directory in a collection. To include a documentation fragment, add ``extends_documentation_fragment: FRAGMENT_NAME`` in your module documentation. Use the fully qualified collection name for the FRAGMENT_NAME (for example, ``kubernetes.core.k8s_auth_options``)."
msgstr "複数の関連モジュールを記述している場合は、認証の詳細やファイルモードの設定、``notes:`` や ``seealso:`` のエントリーなど、共通のドキュメントを共有していることがあります。そのような情報を各モジュールの ``DOCUMENTATION`` ブロックに複製するのではなく、doc_fragment プラグインとして一度保存し、各モジュールのドキュメントで使用することができます。Ansible では、共有ドキュメントフラグメントは、`lib/ansible/plugins/doc_fragments/ <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/doc_fragments>`_ の ``ModuleDocFragment`` クラス、またはコレクションの同等のディレクトリーに含まれています。ドキュメントフラグメントを含めるには、モジュールのドキュメントに ``extends_documentation_fragment: FRAGMENT_NAME`` を追加します。FRAGMENT_NAME には、完全修飾されたコレクション名を使用します (例: ``kubernetes.core.k8s_auth_options``)。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:277
msgid "Modules should only use items from a doc fragment if the module will implement all of the interface documented there in a manner that behaves the same as the existing modules which import that fragment. The goal is that items imported from the doc fragment will behave identically when used in another module that imports the doc fragment."
msgstr "モジュールがドキュメントフラグメントのアイテムを使用するのは、そのフラグメントをインポートする既存のモジュールと同じように動作して、ドキュメント化されたすべてのインターフェースをモジュールが実装する場合のみです。目標は、ドキュメントフラグメントからインポートされたアイテムが、ドキュメントフラグメントをインポートする別のモジュールで使用された場合と同じように動作することです。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:279
msgid "By default, only the ``DOCUMENTATION`` property from a doc fragment is inserted into the module documentation. It is possible to define additional properties in the doc fragment in order to import only certain parts of a doc fragment or mix and match as appropriate. If a property is defined in both the doc fragment and the module, the module value overrides the doc fragment."
msgstr "デフォルトでは、ドキュメントフラグメントの ``DOCUMENTATION`` プロパティーがモジュールのドキュメントに挿入されます。ドキュメントフラグメントの特定の部分のみをインポートするため、または必要に応じて組み合わせて一致させるために、ドキュメントフラグメントに追加のプロパティーを定義することができます。プロパティーがドキュメントフラグメントとモジュールの両方で定義されている場合、モジュール値はドキュメントフラグメントを上書きします。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:281
msgid "Here is an example doc fragment named ``example_fragment.py``:"
msgstr "以下は、``example_fragment.py`` という名前のドキュメントフラグメントの例です。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:299
msgid "To insert the contents of ``OTHER`` in a module:"
msgstr "``OTHER`` の内容をモジュールに挿入するには、以下を行います。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:305
msgid "Or use both :"
msgstr "または、以下の両方を使用してください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:318
msgid "Since Ansible 2.8, you can have user-supplied doc_fragments by using a ``doc_fragments`` directory adjacent to play or role, just like any other plugin."
msgstr "Ansible 2.8 以降、その他のプラグインと同様に、プレイやロールに隣接する ``doc_fragments`` ディレクトリーを使用することで、ユーザーが提供するドキュメントフラグメントを設定できます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:320
msgid "For example, all AWS modules should include:"
msgstr "たとえば、すべての AWS モジュールには以下を含める必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:328
msgid ":ref:`docfragments_collections` describes how to incorporate documentation fragments in a collection."
msgstr "「:ref:`docfragments_collections`」では、コレクションにドキュメントのフラグメントを組み込む方法を説明します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:333
msgid "EXAMPLES block"
msgstr "EXAMPLES ブロック"

#: ../../rst/dev_guide/developing_modules_documenting.rst:335
msgid "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."
msgstr "シバンの後、UTF-8 コーディング、著作権表示、ライセンスセクション、および ``DOCUMENTATION`` ブロックの後に ``EXAMPLES`` ブロックが続きます。ここでは、モジュールが実際の例で複数行のプレーンテキスト YAML 形式でどのように機能するかをユーザーに示します。最良の例は、ユーザーがコピーして Playbook に貼り付ける準備ができています。モジュールに変更を加えるたびに、例を確認して更新してください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:337
msgid "Per playbook best practices, each example should include a ``name:`` line:"
msgstr "Playbook のベストプラクティスに基づき、各例には ``name:`` 行が必要です。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:348
msgid "The ``name:`` line should be capitalized and not include a trailing dot."
msgstr "``name:`` 行は大文字にし、末尾のドットは含めないでください。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:350
msgid "Use a fully qualified collection name (FQCN) as a part of the module's name like in the example above. For modules in ``ansible-core``, use the ``ansible.builtin.`` identifier, for example ``ansible.builtin.debug``."
msgstr "上記の例のように、モジュール名の一部として完全修飾コレクション名 (FQCN) を使用します。``ansible-core`` のモジュールの場合は、``ansible.builtin.`` 識別子 (たとえば ``ansible.builtin.debug``) を使用します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:352
msgid "If your examples use boolean options, use yes/no values. Since the documentation generates boolean values as yes/no, having the examples use these values as well makes the module documentation more consistent."
msgstr "サンプルでブール値オプションを使用する場合は、yes/no の値を使用します。ドキュメントによりブール値が yes/no として生成されるため、このサンプルではこれらの値が使用されており、モジュールドキュメントの一貫性が保たれます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:354
msgid "If your module returns facts that are often needed, an example of how to use them can be helpful."
msgstr "モジュールが必要なファクトを返すと、その使用方法の例が便利です。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:359
msgid "RETURN block"
msgstr "RETURN ブロック"

#: ../../rst/dev_guide/developing_modules_documenting.rst:361
msgid "After the shebang, the UTF-8 coding, the copyright line, the license section, ``DOCUMENTATION`` and ``EXAMPLES`` blocks comes the ``RETURN`` block. This section documents the information the module returns for use by other modules."
msgstr "シバン、UTF-8コーディング、著作権表示、ライセンスセクション、``DOCUMENTATION`` ブロックおよび ``EXAMPLES`` ブロックの後に、``RETURN`` ブロックが続きます。このセクションでは、モジュールが他のモジュールで使用するために返す情報を説明します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:363
msgid "If your module doesn't return anything (apart from the standard returns), this section of your module should read: ``RETURN = r''' # '''`` Otherwise, for each value returned, provide the following fields. All fields are required unless specified otherwise."
msgstr "モジュールが何も返さない場合は (標準の戻り値とは異なり)、モジュールのこのセクションは ``RETURN = r''' # '''`` を読み取る必要があります。それ以外の場合は、返された各値に以下のフィールドを指定します。特に指定がない場合はすべてのフィールドが必要になります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "return name"
msgstr "return name"

#: ../../rst/dev_guide/developing_modules_documenting.rst:367
msgid "Name of the returned field."
msgstr "返されるフィールドの名前。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:370
msgid "Detailed description of what this value represents. Capitalized and with trailing dot."
msgstr "この値が表す内容の詳細な説明。大文字で、末尾のドットを使用します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "returned"
msgstr "returned"

#: ../../rst/dev_guide/developing_modules_documenting.rst:372
msgid "When this value is returned, such as ``always``, ``changed`` or ``success``. This is a string and can contain any human-readable content."
msgstr "``always``、``changed``、``success`` などのこの値が返されると、これは文字列となり、人間が判読できるコンテンツを含めることができます。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:374
msgid "Data type."
msgstr "データ型。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:376
msgid "If ``type='list'``, specifies the data type of the list's elements."
msgstr "``type='list'`` の場合は、リストの要素のデータタイプを指定します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "sample"
msgstr "sample"

#: ../../rst/dev_guide/developing_modules_documenting.rst:378
msgid "One or more examples."
msgstr "1 つ以上の例。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:380
msgid "Only needed if this return was extended after initial Ansible release, in other words, this is greater than the top level `version_added` field. This is a string, and not a float, for example, ``version_added: '2.3'``."
msgstr "これは、最初の Ansible リリースの後にこの返された場合にのみ必要です。つまり、これは最上位レベルの `version_added` フィールドよりも大きくなります。これは浮動小数点ではなく、文字列です (例: ``version_added: '2.3'``)。"

#: ../../rst/dev_guide/developing_modules_documenting.rst
msgid "contains"
msgstr "contains"

#: ../../rst/dev_guide/developing_modules_documenting.rst:383
msgid "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."
msgstr "任意です。ネストされた戻り値を記述するには、``type: dict`` または ``type: list``/``elements: dict`` を設定するか、本当に必要であれば ``type: complex`` を設定し、各サブフィールドに対して上記の要素を繰り返します。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:385
msgid "Here are two example ``RETURN`` sections, one with three simple fields and one with a complex nested field:"
msgstr "以下の例は、``RETURN`` セクションを 3 つの単純なフィールドと、複雑なネストされたフィールドを持つ 2 つのセクションです。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:435
msgid "Python imports"
msgstr "Python のインポート"

#: ../../rst/dev_guide/developing_modules_documenting.rst:437
msgid "After the shebang, the UTF-8 coding, the copyright line, the license, and the sections for ``DOCUMENTATION``, ``EXAMPLES``, and ``RETURN``, you can finally add the python imports. All modules must use Python imports in the form:"
msgstr "シバンの後には、UTF-8 コード行、著作権行、ライセンス、および ``DOCUMENTATION``、``EXAMPLES``、および ``RETURN`` のセクションが最後に python インポートを追加できます。すべてのモジュールは、この形式の Python インポートを使用する必要があります。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:443
msgid "The use of \"wildcard\" imports such as ``from module_utils.basic import *`` is no longer allowed."
msgstr "``from module_utils.basic import *`` などの「ワイルドカード」インポートの使用は許可されなくなりました。"

#: ../../rst/dev_guide/developing_modules_documenting.rst:448
#: ../../rst/dev_guide/testing_documentation.rst:7
msgid "Testing module documentation"
msgstr "モジュールドキュメンテーションのテスト"

#: ../../rst/dev_guide/developing_modules_documenting.rst:450
msgid "To test Ansible documentation locally please :ref:`follow instruction<testing_module_documentation>`. To test documentation in collections, please see :ref:`build_collection_docsite`."
msgstr "Ansible ドキュメントをローカルでテストする方法は、:ref:`<testing_module_documentation>の指示に従います。`また、コレクションのドキュメントをテストする場合は、:ref:`build_collection_docsite` を参照してください。"

#: ../../rst/dev_guide/developing_modules_general.rst:6
msgid "Developing modules"
msgstr "モジュールの開発"

#: ../../rst/dev_guide/developing_modules_general.rst:8
msgid "A module is a reusable, standalone script that Ansible runs on your behalf, either locally or remotely. Modules interact with your local machine, an API, or a remote system to perform specific tasks like changing a database password or spinning up a cloud instance. Each module can be used by the Ansible API, or by the :command:`ansible` or :command:`ansible-playbook` programs. A module provides a defined interface, accepts arguments, and returns information to Ansible by printing a JSON string to stdout before exiting."
msgstr "モジュールは、Ansible がローカルまたはリモートのいずれかで実行する再利用可能なスタンドアロンスクリプトです。モジュールは、ローカルマシン、API、またはリモートシステムと対話し、データベースパスワードの変更やクラウドインスタンスの起動などの特定のタスクを実行します。各モジュールは、Ansible API または :command:`ansible` または :command:`ansible-playbook` プログラムで使用できます。モジュールは定義されたインターフェースを提供し、引数を受け入れ、終了前に JSON 文字列を stdout に出力して Ansible に情報を返します。"

#: ../../rst/dev_guide/developing_modules_general.rst:10
msgid "If you need functionality that is not available in any of the thousands of Ansible modules found in collections, you can easily write your own custom module. When you write a module for local use, you can choose any programming language and follow your own rules. Use this topic to learn how to create an Ansible module in Python. After you create a module, you must add it locally to the appropriate directory so that Ansible can find and execute it. For details about adding a module locally, see :ref:`developing_locally`."
msgstr "コレクションにある数千の Ansible モジュールで利用できない機能が必要な場合は、独自のカスタムモジュールを簡単に作成できます。ローカルで使用するためのモジュールを作成する場合は、任意のプログラミング言語を選択して、独自のルールに従うようにすることができます。本トピックを使用して、Python で Ansible モジュールを作成する方法を説明します。モジュールを作成したら、Ansible が検出および実行できるように、これを適切なディレクトリーにローカルに追加する必要があります。ローカルでモジュールを追加する方法は、「:ref:`developing_locally`」を参照してください。"

#: ../../rst/dev_guide/developing_modules_general.rst:12
msgid "If you are developing a module in a :ref:`collection <developing_collections>`,  see those documents instead."
msgstr ":ref:`collection <developing_collections>` でモジュールを開発する場合は、代わりにそれらのドキュメントを参照してください。"

#: ../../rst/dev_guide/developing_modules_general.rst:20
msgid "Preparing an environment for developing Ansible modules"
msgstr "Ansible モジュール開発用の環境の準備"

#: ../../rst/dev_guide/developing_modules_general.rst:22
msgid "You just need ``ansible-core`` installed to test the module. Modules can be written in any language, but most of the following guide is assuming you are using Python. Modules for inclusion in Ansible itself must be Python or Powershell."
msgstr "モジュールをテストするために必要なのは ``ansible-core`` のインストールのみです。モジュールはどの言語でも記述できますが、以下のガイドのほとんどは Python の使用を前提としています。Ansible 自体に含めるモジュールは Python または Powershell である必要があります。"

#: ../../rst/dev_guide/developing_modules_general.rst:26
msgid "One advantage of using Python or Powershell for your custom modules is being able to use the ``module_utils`` common code that does a lot of the heavy lifting for argument processing, logging and response writing, among other things."
msgstr "カスタムモジュールに Python または Powershell を使用する利点の 1 つは、引数処理、ロギング、応答の書き込みなど多くの面倒な処理が可能な ``module_utils`` の一般的なコードを使用できることです。"

#: ../../rst/dev_guide/developing_modules_general.rst:30
msgid "Creating a module"
msgstr "モジュールの作成"

#: ../../rst/dev_guide/developing_modules_general.rst:32
msgid "It is highly recommended that you use a ``venv`` or ``virtualenv`` for Python development."
msgstr "Python の開発には、``venv`` または ``virtualenv`` を使用することを強く推奨します。"

#: ../../rst/dev_guide/developing_modules_general.rst:34
msgid "To create a module:"
msgstr "モジュールを作成するには、以下を行います。"

#: ../../rst/dev_guide/developing_modules_general.rst:36
msgid "Create a ``library`` directory in your workspace, your test play should live in the same directory."
msgstr "ワークスペースに ``library`` ディレクトリーを作成します。テストプレイは同じディレクトリーに置く必要があります。"

#: ../../rst/dev_guide/developing_modules_general.rst:37
msgid "Create your new module file: ``$ touch library/my_test.py``. Or just open/create it with your editor of choice."
msgstr "新しいモジュールファイル (``$ touch library/my_test.py``) を作成します。または、選択したエディターでそれを開くか、作成します。"

#: ../../rst/dev_guide/developing_modules_general.rst:38
msgid "Paste the content below into your new module file. It includes the :ref:`required Ansible format and documentation <developing_modules_documenting>`, a simple :ref:`argument spec for declaring the module options <argument_spec>`, and some example code."
msgstr "以下の内容を新しいモジュールファイルに貼り付けます。これには、:ref:`必須の Ansible 形式およびドキュメント <developing_modules_documenting>`、:ref:`モジュールオプションを宣言する単純な引数仕様 <argument_spec>`、およびいくつかのサンプルコードが含まれます。"

#: ../../rst/dev_guide/developing_modules_general.rst:39
msgid "Modify and extend the code to do what you want your new module to do. See the :ref:`programming tips <developing_modules_best_practices>` and :ref:`Python 3 compatibility <developing_python_3>` pages for pointers on writing clean and concise module code."
msgstr "新しいモジュールが実行することを行えるようにコードを変更し、拡張します。余計なものが入っていないモジュールコードや、簡潔なモジュールコードの作成に関するヒントは、「:ref:`プログラミングのヒント <developing_modules_best_practices>`」ページおよび「:ref:`Python 3 互換性 <developing_python_3>`」ページを参照してください。"

#: ../../rst/dev_guide/developing_modules_general.rst:45
msgid "Creating an info or a facts module"
msgstr "情報またはファクトモジュールの作成"

#: ../../rst/dev_guide/developing_modules_general.rst:47
msgid "Ansible gathers information about the target machines using facts modules, and gathers information on other objects or files using info modules. If you find yourself trying to add ``state: info`` or ``state: list`` to an existing module, that is often a sign that a new dedicated ``_facts`` or ``_info`` module is needed."
msgstr "Ansible は、ファクトモジュールを使用してターゲットマシンに関する情報を収集し、info モジュールを使用して他のオブジェクトやファイルに関する情報を収集します。既存のモジュールに ``state: info`` または ``state: list`` を追加しようとする際は、多くの場合、これが新規の専用 ``_facts`` モジュールまたは ``_info`` モジュールが必要になるという署名になります。"

#: ../../rst/dev_guide/developing_modules_general.rst:50
msgid "In Ansible 2.8 and onwards, we have two type of information modules, they are ``*_info`` and ``*_facts``."
msgstr "Ansible 2.8 以降では、2 種類の情報モジュール (``*_info`` および ``*_facts``) があります。"

#: ../../rst/dev_guide/developing_modules_general.rst:52
msgid "If a module is named ``<something>_facts``, it should be because its main purpose is returning ``ansible_facts``. Do not name modules that do not do this with ``_facts``. Only use ``ansible_facts`` for information that is specific to the host machine, for example network interfaces and their configuration, which operating system and which programs are installed."
msgstr "モジュールの名前が ``<something>_facts`` なのは、``ansible_facts`` を返すことが主な目的だからです。これは、``_facts`` でこれを行わないモジュールに名前を付けないでください。ネットワークインターフェースやその設定や、オペレーティングシステムやインストールされているプログラムなど、ホストマシンに固有の情報には ``ansible_facts`` のみを使用してください。"

#: ../../rst/dev_guide/developing_modules_general.rst:55
msgid "Modules that query/return general information (and not ``ansible_facts``) should be named ``_info``. General information is non-host specific information, for example information on online/cloud services (you can access different accounts for the same online service from the same host), or information on VMs and containers accessible from the machine, or information on individual files or programs."
msgstr "(``ansible_facts`` ではなく) 一般情報をクエリーまたは返すモジュールの名前は、``_info`` にする必要があります。オンライン/クラウドサービスに関する情報などの一般的な情報は、ホスト以外の固有の情報 (同じホストから同じオンラインサービスの異なるアカウントにアクセスできる)、マシンからアクセス可能な仮想マシンおよびコンテナーに関する情報、または個々のファイルまたはプログラムに関する情報です。"

#: ../../rst/dev_guide/developing_modules_general.rst:58
msgid "Info and facts modules, are just like any other Ansible Module, with a few minor requirements:"
msgstr "info モジュールおよび facts モジュールには、他の Ansible モジュールと同様に、さほど重要ではない要件があります。"

#: ../../rst/dev_guide/developing_modules_general.rst:60
msgid "They MUST be named ``<something>_info`` or ``<something>_facts``, where <something> is singular."
msgstr "名前は ``<something>_info`` または ``<something>_facts`` です。<something> は単数になります。"

#: ../../rst/dev_guide/developing_modules_general.rst:61
msgid "Info ``*_info`` modules MUST return in the form of the :ref:`result dictionary<common_return_values>` so other modules can access them."
msgstr "info の ``*_info`` モジュールは、他のモジュールがアクセスできるように :ref:`結果ディレクトリー<common_return_values>` の形式で返す必要があります。"

#: ../../rst/dev_guide/developing_modules_general.rst:62
msgid "Fact ``*_facts`` modules MUST return in the ``ansible_facts`` field of the :ref:`result dictionary<common_return_values>` so other modules can access them."
msgstr "fact の ``*_facts`` モジュールは、他のモジュールがそれらにアクセスできるように :ref:`結果ディレクトリー<common_return_values>` の ``ansible_facts`` フィールドに返す必要があります。"

#: ../../rst/dev_guide/developing_modules_general.rst:63
msgid "They MUST support :ref:`check_mode <check_mode_dry>`."
msgstr ":ref:`check_mode <check_mode_dry>` をサポートする必要があります。"

#: ../../rst/dev_guide/developing_modules_general.rst:64
msgid "They MUST NOT make any changes to the system."
msgstr "システムに変更を加えないでください。"

#: ../../rst/dev_guide/developing_modules_general.rst:65
msgid "They MUST document the :ref:`return fields<return_block>` and :ref:`examples<examples_block>`."
msgstr ":ref:`return fields<return_block>` および :ref:`examples<examples_block>` を文書化する必要があります。"

#: ../../rst/dev_guide/developing_modules_general.rst:67
msgid "The rest is just like creating a normal module."
msgstr "残りは通常のモジュールを作成するのと同じです。"

#: ../../rst/dev_guide/developing_modules_general.rst:70
msgid "Verifying your module code"
msgstr "モジュールコードの確認"

#: ../../rst/dev_guide/developing_modules_general.rst:72
msgid "After you modify the sample code above to do what you want, you can try out your module. Our :ref:`debugging tips <debugging_modules>` will help if you run into bugs as you verify your module code."
msgstr "上記のサンプルコードを修正したら、モジュールを試すことができます。:ref:`デバッグのヒント <debugging_modules>` は、モジュールコードを検証する際にバグが発生した場合に役立ちます。"

#: ../../rst/dev_guide/developing_modules_general.rst:77
msgid "Verifying your module code locally"
msgstr "モジュールコードのローカルでの確認"

#: ../../rst/dev_guide/developing_modules_general.rst:79
msgid "The simplest way is to use ``ansible`` adhoc command:"
msgstr "最も簡単な方法は、``ansible`` アドホックコマンドを使用することです。"

#: ../../rst/dev_guide/developing_modules_general.rst:85
msgid "If your module does not need to target a remote host, you can quickly and easily exercise your code locally like this:"
msgstr "モジュールがリモートホストを対象にする必要がない場合は、以下のようにコードをローカルで簡単に使用できます。"

#: ../../rst/dev_guide/developing_modules_general.rst:91
msgid "If for any reason (pdb, using print(), faster iteration, etc) you want to avoid going through Ansible, another way is to create an arguments file, a basic JSON config file that passes parameters to your module so that you can run it. Name the arguments file ``/tmp/args.json`` and add the following content:"
msgstr "何らかの理由で (pdb、print()、より高速な反復など) Ansible の使用を回避したい場合は、モジュールに引数ファイル (パラメーターを渡す基本的な JSON 設定ファイル) を作成して実行できるようにします。この引数ファイルには ``/tmp/args.json`` という名前を付け、以下の内容を追加します。"

#: ../../rst/dev_guide/developing_modules_general.rst:104
msgid "Then the module can be tested locally and directly. This skips the packing steps and uses module_utils files directly:"
msgstr "モジュールはローカルで直接テストできるようになります。これにより、パッキングの手順が省略され、module_utils ファイルを直接使用できます。"

#: ../../rst/dev_guide/developing_modules_general.rst:110
msgid "It should return output like this:"
msgstr "この場合、以下のような出力が返されます。"

#: ../../rst/dev_guide/developing_modules_general.rst:119
msgid "Verifying your module code in a playbook"
msgstr "Playbook でのモジュールコードの確認"

#: ../../rst/dev_guide/developing_modules_general.rst:121
msgid "You can easily run a full test by including it in a playbook, as long as the ``library`` directory is in the same directory as the play:"
msgstr "``library`` ディレクトリーがプレイと同じディレクトリーにある限り、Playbook に追加して完全なテストを簡単に実行できます。"

#: ../../rst/dev_guide/developing_modules_general.rst:123
msgid "Create a playbook in any directory: ``$ touch testmod.yml``"
msgstr "任意のディレクトリーに Playbook を作成します (``$ touch testmod.yml``)。"

#: ../../rst/dev_guide/developing_modules_general.rst:124
msgid "Add the following to the new playbook file:"
msgstr "以下を新しい Playbook ファイルに追加します。"

#: ../../rst/dev_guide/developing_modules_general.rst:140
msgid "Run the playbook and analyze the output: ``$ ansible-playbook ./testmod.yml``"
msgstr "Playbook を実行し、出力を分析します (``$ ansible-playbook ./testmod.yml``)。"

#: ../../rst/dev_guide/developing_modules_general.rst:143
msgid "Testing your newly-created module"
msgstr "新たに作成したモジュールのテスト"

#: ../../rst/dev_guide/developing_modules_general.rst:145
msgid "The following two examples will get you started with testing your module code. Please review our :ref:`testing <developing_testing>` section for more detailed information, including instructions for :ref:`testing module documentation <testing_module_documentation>`, adding :ref:`integration tests <testing_integration>`, and more."
msgstr "以下の 2 つの例は、モジュールコードのテストを開始します。:ref:`モジュールのテストのドキュメント <testing_module_documentation>` の手順、:ref:`統合テスト <testing_integration>` の追加などの詳細な情報は、:ref:`テスト <developing_testing>` のセクションを参照してください。"

#: ../../rst/dev_guide/developing_modules_general.rst:149
msgid "If contributing to Ansible, every new module and plugin should have integration tests, even if the tests cannot be run on Ansible CI infrastructure. In this case, the tests should be marked with the ``unsupported`` alias in `aliases file <https://docs.ansible.com/ansible/latest/dev_guide/testing/sanity/integration-aliases.html>`_."
msgstr "Ansible に貢献する場合、テストを Ansible CI インフラストラクチャーで実行できなくても、新しいモジュールとプラグインには統合テストが必要です。この場合、テストは `aliases file <https://docs.ansible.com/ansible/latest/dev_guide/testing/sanity/integration-aliases.html>`_ の ``unsupported`` エイリアスでマーク付けする必要があります。"

#: ../../rst/dev_guide/developing_modules_general.rst:153
msgid "Performing sanity tests"
msgstr "健全性テストの実行"

#: ../../rst/dev_guide/developing_modules_general.rst:155
msgid "You can run through Ansible's sanity checks in a container:"
msgstr "Ansible の健全性チェックをコンテナーで実行できます。"

#: ../../rst/dev_guide/developing_modules_general.rst:157
msgid "``$ ansible-test sanity -v --docker --python 3.10 MODULE_NAME``"
msgstr "``$ ansible-test sanity -v --docker --python 3.10 MODULE_NAME``"

#: ../../rst/dev_guide/developing_modules_general.rst:160
msgid "Note that this example requires Docker to be installed and running. If you'd rather not use a container for this, you can choose to use ``--venv`` instead of ``--docker``."
msgstr "この例では、Docker をインストールして実行する必要があります。コンテナーを使用しない場合は、``--docker`` の代わりに ``--venv`` を使用できます。"

#: ../../rst/dev_guide/developing_modules_general.rst:164
msgid "Contributing back to Ansible"
msgstr "Ansible への貢献"

#: ../../rst/dev_guide/developing_modules_general.rst:166
msgid "If you would like to contribute to ``ansible-core`` by adding a new feature or fixing a bug, `create a fork <https://help.github.com/articles/fork-a-repo/>`_ of the ansible/ansible repository and develop against a new feature branch using the ``devel`` branch as a starting point. When you have a good working code change, you can submit a pull request to the Ansible repository by selecting your feature branch as a source and the Ansible devel branch as a target."
msgstr "新しい機能を追加したりバグを修正したりして、``ansible-core`` に貢献する場合は、ansible/ansible リポジトリーの `フォークの作成 <https://help.github.com/articles/fork-a-repo/>`_ し、開始点として ``devel`` ブランチを使用して新機能ブランチに対して開発します。適切な作業コードも変更がある場合は、機能ブランチをソースとして、および Ansible devel ブランチをターゲットとして選択し、Ansible リポジトリーにプル要求を送信します。"

#: ../../rst/dev_guide/developing_modules_general.rst:168
msgid "If you want to contribute a module to an :ref:`Ansible collection <contributing_maintained_collections>`, review our :ref:`submission checklist <developing_modules_checklist>`, :ref:`programming tips <developing_modules_best_practices>`, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility <developing_python_3>`, as well as information about :ref:`testing <developing_testing>` before you open a pull request."
msgstr "モジュールを :ref:`Ansible コレクション <contributing_maintained_collections>` に提供する場合は、「:ref:`提出のチェックアウト <developing_modules_checklist>`」、「:ref:`プログラムのヒント <developing_modules_best_practices>`」、ならびに「:ref:`Python 2 および Python 3 の互換性を維持するストラテジー <developing_python_3>`」を確認してください。プル要求を作成する前に、:ref:`テスト <developing_testing>` に関する情報も併せて参照してください。"

#: ../../rst/dev_guide/developing_modules_general.rst:170
msgid "The :ref:`Community Guide <ansible_community_guide>` covers how to open a pull request and what happens next."
msgstr "『:ref:`コミュニティーガイド <ansible_community_guide>`』では、プル要求を開く方法と、次に実行することを説明します。"

#: ../../rst/dev_guide/developing_modules_general.rst:174
msgid "Communication and development support"
msgstr "通信および開発のサポート"

#: ../../rst/dev_guide/developing_modules_general.rst:176
msgid "Join the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat <https://libera.chat/>`_) for discussions surrounding Ansible development."
msgstr "``#ansible-devel`` チャットチャンネル（ansible.imでMatrixを使用、または`irc.libera.chat <https://libera.chat/>`でIRCを使用）に参加して、Ansible の開発に関する議論を行います。"

#: ../../rst/dev_guide/developing_modules_general.rst:178
msgid "For questions and discussions pertaining to using the Ansible product, join the ``#ansible`` channel."
msgstr "Ansible 製品の使用に関する質問および貢献については、``#ansible`` チャンネルに参加します。"

#: ../../rst/dev_guide/developing_modules_general.rst:180
msgid "To find other topic-specific chat channels, look at :ref:`Community Guide, Communicating <communication_irc>`."
msgstr "他のトピック固有のチャットチャンネルを探すには、:ref:`Community Guide, Communicating <communication_irc>` をご覧ください。"

#: ../../rst/dev_guide/developing_modules_general.rst:183
msgid "Credit"
msgstr "謝辞"

#: ../../rst/dev_guide/developing_modules_general.rst:185
msgid "Thank you to Thomas Stringer (`@trstringer <https://github.com/trstringer>`_) for contributing source material for this topic."
msgstr "このトピックの元となる資料を提供していただいた Thomas Stringer (`@trstringer <https://github.com/trstringer>`_) 氏に感謝の意を示します。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:5
msgid "Developing Cisco ACI modules"
msgstr "Cisco ACI モジュールの開発"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:6
msgid "This is a brief walk-through of how to create new Cisco ACI modules for Ansible."
msgstr "Ansible 向けに新しい Cisco ACI モジュールを作成する方法に関する簡単なウォークスルーです。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:8
msgid "For more information about Cisco ACI, look at the :ref:`Cisco ACI user guide <aci_guide>`."
msgstr "Cisco ACI の詳細は、「:ref:`Cisco ACI ユーザーガイド <aci_guide>`」を参照してください。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:10
#: ../../rst/dev_guide/developing_modules_general_windows.rst:13
msgid "What's covered in this section:"
msgstr "本項で取り上げられている内容:"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:20
#: ../../rst/dev_guide/testing_units_modules.rst:14
msgid "Introduction"
msgstr "はじめに"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:21
msgid "The `cisco.aci collection <https://galaxy.ansible.com/cisco/aci>`_ already includes a large number of Cisco ACI modules, however the ACI object model is huge and covering all possible functionality would easily cover more than 1500 individual modules."
msgstr "`cisco.aci collection <https://galaxy.ansible.com/cisco/aci>`_ にはすでに多数の Cisco ACI モジュールが含まれていますが、ACI オブジェクトモデルは大きく、すべての機能に対応するため、1500 以上のモジュールを簡単に対応できます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:23
msgid "If you need specific functionality, you have 2 options:"
msgstr "特定の機能が必要な場合は、2 つのオプションがあります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:25
msgid "Learn the ACI object model and use the low-level APIC REST API using the :ref:`aci_rest <aci_rest_module>` module"
msgstr "ACI オブジェクトモデルを学習し、「:ref:`aci_rest <aci_rest_module>`」モジュールを使用して低レベルの APIC REST API を使用します。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:26
msgid "Write your own dedicated modules, which is actually quite easy"
msgstr "独自の専用モジュールを作成することは、実際には非常に簡単です。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:30
#: ../../rst/dev_guide/developing_modules_general_aci.rst:413
msgid "`Ansible ACI collection <https://github.com/CiscoDevNet/ansible-aci>`_"
msgstr "`Ansible ACI collection <https://github.com/CiscoDevNet/ansible-aci>`_"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:31
#: ../../rst/dev_guide/developing_modules_general_aci.rst:414
msgid "Github repository of the ansible ACI collection"
msgstr "Ansible ACI コレクションの GitHub リポジトリー"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:32
#: ../../rst/dev_guide/developing_modules_general_aci.rst:409
msgid ":ref:`hacking_collections`"
msgstr ":ref:`collections`"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:33
msgid "Information on how to contribute to collections."
msgstr "コレクションへの貢献方法に関する情報。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:34
msgid "`ACI Fundamentals: ACI Policy Model <https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-Fundamentals/b_ACI-Fundamentals_chapter_010001.html>`_"
msgstr "`ACI Fundamentals: ACI Policy Model <https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-Fundamentals/b_ACI-Fundamentals_chapter_010001.html>`_"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:35
msgid "A good introduction to the ACI object model."
msgstr "ACI オブジェクトモデルの優れた概要"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:36
msgid "`APIC Management Information Model reference <https://developer.cisco.com/docs/apic-mim-ref/>`_"
msgstr "`APIC Management Information Model reference <https://developer.cisco.com/docs/apic-mim-ref/>`_"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:37
msgid "Complete reference of the APIC object model."
msgstr "APIC オブジェクトモデルの完全なリファレンス"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:38
msgid "`APIC REST API Configuration Guide <https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/2-x/rest_cfg/2_1_x/b_Cisco_APIC_REST_API_Configuration_Guide.html>`_"
msgstr "`APIC REST API Configuration Guide <https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/2-x/rest_cfg/2_1_x/b_Cisco_APIC_REST_API_Configuration_Guide.html>`_"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:39
msgid "Detailed guide on how the APIC REST API is designed and used, incl. many examples."
msgstr "APIC REST API を設計および使用する方法についての詳細ガイド。多数の例があります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:42
msgid "So let's look at how a typical ACI module is built up."
msgstr "それでは、典型的な ACI モジュールがどのように構築されるかを見てみましょう。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:48
msgid "ACI module structure"
msgstr "ACI モジュール構造"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:51
msgid "Importing objects from Python libraries"
msgstr "Python ライブラリーからのオブジェクトのインポート"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:52
msgid "The following imports are standard across ACI modules:"
msgstr "以下のインポートは、ACI モジュール全体で標準のものです。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:61
msgid "Defining the argument spec"
msgstr "引数仕様の定義"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:62
msgid "The first line adds the standard connection parameters to the module. After that, the next section will update the ``argument_spec`` dictionary with module-specific parameters. The module-specific parameters should include:"
msgstr "最初の行は、標準の接続パラメーターをモジュールに追加します。その後、以下のセクションはモジュール固有のパラメーターで ``argument_spec`` ディクショナリーを更新します。モジュール固有のパラメーターには以下が含まれます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:64
msgid "the object_id (usually the name)"
msgstr "object_id (通常は名前)"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:65
msgid "the configurable properties of the object"
msgstr "オブジェクトの設定可能なプロパティー"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:66
msgid "the parent object IDs (all parents up to the root)"
msgstr "親オブジェクト ID (ルートまでのすべての親)"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:67
msgid "only child classes that are a 1-to-1 relationship (1-to-many/many-to-many require their own module to properly manage)"
msgstr "1 対 1 の関係である子クラスのみ (1 対多/多対多では、独自のモジュールを適切に管理する必要があります)"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:68
msgid "the state"
msgstr "状態"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:70
msgid "``state: absent`` to ensure object does not exist"
msgstr "``state: absent``: オブジェクトが存在しないことを確認する"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:71
msgid "``state: present`` to ensure the object and configs exist; this is also the default"
msgstr "``state: present``: オブジェクトと設定が存在することを確認する (デフォルト)"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:72
msgid "``state: query`` to retrieve information about objects in the class"
msgstr "``state: query``: クラスのオブジェクトに関する情報を取得する"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:90
msgid "Do not provide default values for configuration arguments. Default values could cause unintended changes to the object."
msgstr "設定引数のデフォルト値を指定しないでください。デフォルト値により、オブジェクトへの意図しない変更が生じる可能性があります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:93
msgid "Using the AnsibleModule object"
msgstr "AnsibleModule オブジェクトの使用"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:94
msgid "The following section creates an AnsibleModule instance. The module should support check-mode, so we pass the ``argument_spec`` and  ``supports_check_mode`` arguments. Since these modules support querying the APIC for all objects of the module's class, the object/parent IDs should only be required if ``state: absent`` or ``state: present``."
msgstr "次のセクションでは、AnsibleModule インスタンスを作成します。モジュールはチェックモードをサポートする必要があるため、``argument_spec`` 引数および ``supports_check_mode`` 引数を渡します。これらのモジュールは、モジュールのクラスのすべてのオブジェクトに対する APIC のクエリーをサポートするため、オブジェクト/親 ID は、``state: absent`` または ``state: present`` の場合に限り必要になります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:109
msgid "Mapping variable definition"
msgstr "マッピング変数定義"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:110
msgid "Once the AnsibleModule object has been initiated, the necessary parameter values should be extracted from ``params`` and any data validation should be done. Usually the only params that need to be extracted are those related to the ACI object configuration and its child configuration. If you have integer objects that you would like to validate, then the validation should be done here, and the ``ACIModule.payload()`` method will handle the string conversion."
msgstr "AnsibleModule オブジェクトが開始されたら、必要なパラメーターの値を ``params`` から抽出し、データの検証を行う必要があります。通常、抽出する必要がある唯一のパラメーターが ACI オブジェクトの設定およびその子設定に関連するパラメーターのみとなります。検証する整数オブジェクトがある場合は、検証を行う必要があります。データ検証はここで行う必要があり、``ACIModule.payload()`` メソッドは変換文字列を処理する必要があります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:126
msgid "Using the ACIModule object"
msgstr "ACIModule オブジェクトの使用"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:127
msgid "The ACIModule class handles most of the logic for the ACI modules. The ACIModule extends functionality to the AnsibleModule object, so the module instance must be passed into the class instantiation."
msgstr "ACIModule クラスは、ACI モジュールのロジックの大部分を処理します。ACIModule は機能を AnsibleModule オブジェクトに拡張するため、モジュールインスタンスをクラスのインスタンス化に渡す必要があります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:133
msgid "The ACIModule has six main methods that are used by the modules:"
msgstr "ACIModule には、モジュールによって使用される 6 つの主なメソッドがあります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:135
msgid "construct_url"
msgstr "construct_url"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:136
msgid "get_existing"
msgstr "get_existing"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:137
msgid "payload"
msgstr "payload"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:138
msgid "get_diff"
msgstr "get_diff"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:139
msgid "post_config"
msgstr "post_config"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:140
msgid "delete_config"
msgstr "delete_config"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:142
msgid "The first two methods are used regardless of what value is passed to the ``state`` parameter."
msgstr "最初の 2 つのメソッドは、``state`` パラメーターに渡される値に関係なく使用されます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:145
msgid "Constructing URLs"
msgstr "URL の構築"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:146
msgid "The ``construct_url()`` method is used to dynamically build the appropriate URL to interact with the object, and the appropriate filter string that should be appended to the URL to filter the results."
msgstr "``construct_url()`` メソッドは、オブジェクトと対話するために適切な URL と、URL に追加して結果にフィルターを設定する適切なフィルター文字列を動的に構築するのに使用されます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:148
msgid "When the ``state`` is not ``query``, the URL is the base URL to access the APIC plus the distinguished name to access the object. The filter string will restrict the returned data to just the configuration data."
msgstr "``state`` が ``query`` でない場合、URL は APIC にアクセスするベース URL と、オブジェクトにアクセスするための識別名です。フィルター文字列は返されたデータを設定データにのみ制限します。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:149
msgid "When ``state`` is ``query``, the URL and filter string used depends on what parameters are passed to the object. This method handles the complexity so that it is easier to add new modules and so that all modules are consistent in what type of data is returned."
msgstr "``state`` が ``query`` される場合、使用される URL およびフィルター文字列は、オブジェクトに渡されるパラメーターによって異なります。この方法は複雑性を処理するため、新しいモジュールの追加が容易になります。また、すべてのモジュールがどのタイプのデータを返すかに一貫性を持たせるようにします。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:151
msgid "Our design goal is to take all ID parameters that have values, and return the most specific data possible. If you do not supply any ID parameters to the task, then all objects of the class will be returned. If your task does consist of ID parameters sed, then the data for the specific object is returned. If a partial set of ID parameters are passed, then the module will use the IDs that are passed to build the URL and filter strings appropriately."
msgstr "この設計の目的は、値があるすべての ID パラメーターを取り、最も具体的なデータを返すことです。ID パラメーターをタスクに指定しないと、クラスのすべてのオブジェクトが返されます。タスクが ID パラメーター sed で構成されている場合は、特定のオブジェクトのデータが返されます。ID パラメーターの一部が渡されると、モジュールは URL およびフィルター文字列を適切にビルドするために渡された ID を使用します。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:153
msgid "The ``construct_url()`` method takes 2 required arguments:"
msgstr "``construct_url()`` メソッドは、必要な引数を 2 つ取ります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:155
msgid "**self** - passed automatically with the class instance"
msgstr "**self** - クラスインスタンスで自動的に渡されます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:156
msgid "**root_class** - A dictionary consisting of ``aci_class``, ``aci_rn``, ``target_filter``, and ``module_object`` keys"
msgstr "**root_class**: ``aci_class`` キー、``aci_rn`` キー、``target_filter`` キー、および ``module_object`` キーで構成されるディクショナリー"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:158
msgid "**aci_class**: The name of the class used by the APIC, for example ``fvTenant``"
msgstr "**aci_class**: APIC が使用するクラス名 (例: ``fvTenant``)"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:160
msgid "**aci_rn**: The relative name of the object, for example ``tn-ACME``"
msgstr "**aci_rn**: オブジェクトの相対名 (例: ``tn-ACME``)"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:162
msgid "**target_filter**: A dictionary with key-value pairs that make up the query string for selecting a subset of entries, for example ``{'name': 'ACME'}``"
msgstr "**target_filter**: エントリーのサブセットを選択するクエリー文字列を構成するキーと値のペアを持つディクショナリー (例: ``{'name': 'ACME'}``)"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:164
msgid "**module_object**: The particular object for this class, for example ``ACME``"
msgstr "**module_object**: このクラスの特定のオブジェクト (例: ``ACME``)"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:166
#: ../../rst/dev_guide/developing_program_flow_modules.rst:599
#: ../../rst/dev_guide/developing_program_flow_modules.rst:638
#: ../../rst/dev_guide/developing_program_flow_modules.rst:652
#: ../../rst/dev_guide/developing_program_flow_modules.rst:752
#: ../../rst/dev_guide/developing_program_flow_modules.rst:769
#: ../../rst/dev_guide/developing_program_flow_modules.rst:783
#: ../../rst/dev_guide/developing_program_flow_modules.rst:810
#: ../../rst/dev_guide/developing_program_flow_modules.rst:827
#: ../../rst/dev_guide/testing_units_modules.rst:90
#: ../../rst/dev_guide/testing_units_modules.rst:109
msgid "Example:"
msgstr "例: "

#: ../../rst/dev_guide/developing_modules_general_aci.rst:179
msgid "Some modules, like ``aci_tenant``, are the root class and so they would not need to pass any additional arguments to the method."
msgstr "``aci_tenant`` などの一部のモジュールは root クラスであるため、メソッドに追加の引数を渡す必要はありません。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:181
msgid "The ``construct_url()`` method takes 4 optional arguments, the first three imitate the root class as described above, but are for child objects:"
msgstr "``construct_url()`` メソッドは、4 つの任意の引数を取ります。最初の 3 つの引数が上記のように root クラスを模倣しますが、これは子オブジェクト用です。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:183
msgid "subclass_1 - A dictionary consisting of ``aci_class``, ``aci_rn``, ``target_filter``, and ``module_object`` keys"
msgstr "subclass_1 - ``aci_class`` キー、``aci_rn`` キー、``target_filter`` キー、および ``module_object`` キーで構成されるディクショナリー"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:185
msgid "Example: Application Profile Class (AP)"
msgstr "例: Application Profile Class (AP)"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:187
msgid "subclass_2 - A dictionary consisting of ``aci_class``, ``aci_rn``, ``target_filter``, and ``module_object`` keys"
msgstr "subclass_2 - ``aci_class`` キー、``aci_rn`` キー、``target_filter`` キー、および ``module_object`` キーで構成されるディクショナリー"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:189
msgid "Example: End Point Group (EPG)"
msgstr "例: エンドポイントグループ (EPG)"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:191
msgid "subclass_3 - A dictionary consisting of ``aci_class``, ``aci_rn``, ``target_filter``, and ``module_object`` keys"
msgstr "subclass_3 - ``aci_class`` キー、``aci_rn`` キー、``target_filter`` キー、および ``module_object`` キーで構成されるディクショナリー"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:193
msgid "Example: Binding a Contract to an EPG"
msgstr "例: EPG への契約のバインド"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:195
msgid "child_classes - The list of APIC names for the child classes supported by the modules."
msgstr "child_classes - モジュールがサポートする子クラスの APIC 名のリスト"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:197
msgid "This is a list, even if it is a list of one"
msgstr "1 つのリストであっても、これはリストです。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:198
msgid "These are the unfriendly names used by the APIC"
msgstr "これらは、APIC が使用する分かりにくい名前です。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:199
msgid "These are used to limit the returned child_classes when possible"
msgstr "可能な場合は、返された child_classes を制限するのに使用されます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:200
msgid "Example: ``child_classes=['fvRsBDSubnetToProfile', 'fvRsNdPfxPol']``"
msgstr "例: ``child_classes=['fvRsBDSubnetToProfile', 'fvRsNdPfxPol']``"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:202
msgid "Sometimes the APIC will require special characters ([, ], and -) or will use object metadata in the name (\"vlanns\" for VLAN pools); the module should handle adding special characters or joining of multiple parameters in order to keep expected inputs simple."
msgstr "APIC は、特殊文字 ([, ]、および -) を要求したり、名前にオブジェクトのメタデータ (「VLAN」プールの場合は「vlanns」) を使用したりすることがあります。モジュールは、予想される入力の単純さに保つために、特殊文字の追加または複数のパラメーターの結合を処理する必要があります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:205
msgid "Getting the existing configuration"
msgstr "既存設定の取得"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:206
msgid "Once the URL and filter string have been built, the module is ready to retrieve the existing configuration for the object:"
msgstr "URL およびフィルター文字列が構築されると、モジュールはオブジェクトの既存の設定を取得できるようになります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:208
msgid "``state: present`` retrieves the configuration to use as a comparison against what was entered in the task. All values that are different than the existing values will be updated."
msgstr "``state: present`` は、タスクに入力した値と比較として使用する設定を取得します。既存の値とは異なる値はすべて更新されます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:209
msgid "``state: absent`` uses the existing configuration to see if the item exists and needs to be deleted."
msgstr "``state: absent`` は、既存の設定を使用して項目が存在し、削除する必要があるかどうかを確認します。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:210
msgid "``state: query`` uses this to perform the query for the task and report back the existing data."
msgstr "``state: query`` は、これを使用してタスクのクエリーを実行し、既存のデータを報告します。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:218
msgid "When state is present"
msgstr "state が present の場合"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:219
msgid "When ``state: present``, the module needs to perform a diff against the existing configuration and the task entries. If any value needs to be updated, then the module will make a POST request with only the items that need to be updated. Some modules have children that are in a 1-to-1 relationship with another object; for these cases, the module can be used to manage the child objects."
msgstr "``state: present`` の場合、モジュールは既存の設定とタスクエントリーに対して diff を実行する必要があります。値を更新する必要がある場合、モジュールは更新が必要なアイテムのみが含まれる POST 要求を行います。モジュールによっては、別のオブジェクトと 1 対 1 の関係にある子があります。これらの場合、モジュールは子オブジェクトを管理するために使用できます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:222
msgid "Building the ACI payload"
msgstr "ACI ペイロードの構築"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:223
msgid "The ``aci.payload()`` method is used to build a dictionary of the proposed object configuration. All parameters that were not provided a value in the task will be removed from the dictionary (both for the object and its children). Any parameter that does have a value will be converted to a string and added to the final dictionary object that will be used for comparison against the existing configuration."
msgstr "``aci.payload()`` メソッドは、提案されたオブジェクト設定のディクショナリー構築に使用されます。タスクで値が提供されていないパラメーターはすべてディクショナリー (オブジェクトとその子の両方) から削除されます。値のあるパラメーターは文字列に変換され、既存の設定との比較に使用される最終ディクショナリーオブジェクトに追加されます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:225
msgid "The ``aci.payload()`` method takes two required arguments and 1 optional argument, depending on if the module manages child objects."
msgstr "``aci.payload()`` メソッドは、モジュールが子オブジェクトを管理するかどうかに応じて、2 つの必須引数と、1 つの任意の引数を取ります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:227
msgid "``aci_class`` is the APIC name for the object's class, for example ``aci_class='fvBD'``"
msgstr "``aci_class`` は、オブジェクトのクラスの APIC 名です。たとえば、``aci_class='fvBD'`` になります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:228
msgid "``class_config`` is the appropriate dictionary to be used as the payload for the POST request"
msgstr "``class_config`` は POST 要求のペイロードとして使用する適切なディクショナリーです。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:230
msgid "The keys should match the names used by the APIC."
msgstr "キーは APIC で使用される名前と一致する必要があります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:231
msgid "The values should be the corresponding value in ``module.params``; these are the variables defined above"
msgstr "``module.params`` の対応する値でなければなりません。これらは上で定義される変数です"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:233
msgid "``child_configs`` is optional, and is a list of child config dictionaries."
msgstr "``child_configs`` は任意であり、子設定のディクショナリーの一覧です。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:235
msgid "The child configs include the full child object dictionary, not just the attributes configuration portion."
msgstr "子設定には、属性設定部分だけでなく、完全な子オブジェクトディクショナリーが含まれます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:236
msgid "The configuration portion is built the same way as the object."
msgstr "設定部分は、オブジェクトと同じ方法で構築されます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:260
msgid "Performing the request"
msgstr "要求の実行"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:261
msgid "The ``get_diff()`` method is used to perform the diff, and takes only one required argument, ``aci_class``. Example: ``aci.get_diff(aci_class='fvBD')``"
msgstr "``get_diff()`` メソッドは diff を実行し、必要な引数 ``aci_class`` を 1 つだけ取ります。たとえば ``aci.get_diff(aci_class='fvBD')`` です。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:264
msgid "The ``post_config()`` method is used to make the POST request to the APIC if needed. This method doesn't take any arguments and handles check mode. Example: ``aci.post_config()``"
msgstr "``post_config()`` メソッドは、必要に応じて APIC への POST 要求を行うために使用されます。このメソッドは引数を受け付けず、チェックモードを処理します。以下に例を示します。たとえば、``aci.post_config()`` になります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:269
msgid "Example code"
msgstr "サンプルコード"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:299
msgid "When state is absent"
msgstr "state が absent の場合"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:300
msgid "If the task sets the state to absent, then the ``delete_config()`` method is all that is needed. This method does not take any arguments, and handles check mode."
msgstr "タスクが state を absent に設定すると、``delete_config()`` メソッドのみが必要になります。このメソッドは引数を取らず、チェックモードを処理します。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:309
msgid "Exiting the module"
msgstr "モジュールの終了"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:310
msgid "To have the module exit, call the ACIModule method ``exit_json()``. This method automatically takes care of returning the common return values for you."
msgstr "モジュールを終了するには、ACIModule メソッド ``exit_json()`` を呼び出します。このメソッドは、一般的な戻り値を返すことを自動的に行います。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:323
msgid "Testing ACI library functions"
msgstr "ACI ライブラリー関数のテスト"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:324
msgid "You can test your ``construct_url()`` and ``payload()`` arguments without accessing APIC hardware by using the following python script:"
msgstr "以下の python スクリプトを使用して、APIC ハードウェアにアクセスせずに ``construct_url()`` 引数および ``payload()`` 引数をテストすることができます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:383
msgid "This will result in:"
msgstr "これにより、以下が生成されます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:397
msgid "Testing for sanity checks"
msgstr "健全性チェックのテスト"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:398
msgid "For legacy versions of ansible, you can run from your fork something like:"
msgstr "Ansible のレガシーバージョンでは、次のようなフォークから実行できます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:404
msgid "Meanwhile, the ACI modules have moved into a collection. Please refer to the links below, which provide detailed guidance how to setup your environment and test the collection."
msgstr "ACI モジュールはコレクションに移動しました。以下のリンクを参照してください。環境を設定してコレクションをテストする方法の詳細なガイダンスが記載されています。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:410
msgid "Information how to setup your environment to contribute to collections"
msgstr "環境を設定してコレクションに貢献する方法"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:411
#: ../../rst/dev_guide/testing.rst:33
msgid ":ref:`testing_sanity`"
msgstr ":ref:`testing_sanity`"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:412
msgid "Information on how to build sanity tests."
msgstr "健全性テストを構築する方法に関する情報"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:418
msgid "Testing ACI integration tests"
msgstr "ACI 統合テストのテスト"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:419
#: ../../rst/dev_guide/developing_modules_general_aci.rst:449
msgid "You can run this:"
msgstr "以下を実行できます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:425
msgid "You may need to add ``--python 2.7`` or ``--python 3.6`` in order to use the correct python version for performing tests."
msgstr "テストの実行に適切な python バージョンを使用するには、``--python 2.7`` または ``--python 3.6`` を追加しないといけない場合があります。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:427
msgid "You may want to edit the used inventory at *test/integration/inventory.networking* and add something like:"
msgstr "*test/integration/inventory.networking* で使用されたインベントリーを編集し、以下のように追加することもできます。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:443
#: ../../rst/dev_guide/testing.rst:37
msgid ":ref:`testing_integration`"
msgstr ":ref:`testing_integration`"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:444
msgid "Information on how to build integration tests."
msgstr "統合テストの構築方法に関する情報。"

#: ../../rst/dev_guide/developing_modules_general_aci.rst:448
msgid "Testing for test coverage"
msgstr "テストカバレージのテスト"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:5
msgid "Windows module development walkthrough"
msgstr "Windows モジュール開発ウォークスルー"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:7
msgid "In this section, we will walk through developing, testing, and debugging an Ansible Windows module."
msgstr "本セクションでは、Ansible Windows モジュールの開発、テスト、およびデバッグの開発手順 (ウォークスルー) を説明します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:10
msgid "Because Windows modules are written in Powershell and need to be run on a Windows host, this guide differs from the usual development walkthrough guide."
msgstr "Windows モジュールは Powershell で書かれており、Windows ホスト上で実行する必要があるため、このガイドは通常の開発ウォークスルーガイドとは異なります。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:20
msgid "Windows environment setup"
msgstr "Windows 環境の設定"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:22
msgid "Unlike Python module development which can be run on the host that runs Ansible, Windows modules need to be written and tested for Windows hosts. While evaluation editions of Windows can be downloaded from Microsoft, these images are usually not ready to be used by Ansible without further modification. The easiest way to set up a Windows host so that it is ready to by used by Ansible is to set up a virtual machine using Vagrant. Vagrant can be used to download existing OS images called *boxes* that are then deployed to a hypervisor like VirtualBox. These boxes can either be created and stored offline or they can be downloaded from a central repository called Vagrant Cloud."
msgstr "Ansible を実行するホストで実行できる Python モジュール開発とは異なり、Windows ホスト用に Windows モジュールを作成およびテストする必要があります。Windows の評価エディションを Microsoft からダウンロードできますが、通常はこれらのイメージを追加の変更なしで Ansible で使用することはできません。Ansible で使用する準備が整うように Windows ホストを設定する最も簡単な方法は、Vagrant を使用して仮想マシンを設定することにあります。Vagrant を使用すると、*ボックス* と呼ばれる既存の OS イメージをダウンロードし、VirtualBox のようなハイパーバイザーにデプロイされます。これらのボックスは、オフラインで作成および保存するか、Vagrant Cloud と呼ばれる中央リポジトリーからダウンロードできます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:33
#, python-format
msgid "This guide will use the Vagrant boxes created by the `packer-windoze <https://github.com/jborean93/packer-windoze>`_ repository which have also been uploaded to `Vagrant Cloud <https://app.vagrantup.com/boxes/search?utf8=%E2%9C%93&sort=downloads&provider=&q=jborean93>`_. To find out more info on how these images are created, please go to the GitHub repo and look at the ``README`` file."
msgstr "本ガイドでは、`packer-windoze <https://github.com/jborean93/packer-windoze>`_ リポジトリーにより作成された Vagrant ボックスを使用します。これは、`Vagrant Cloud <https://app.vagrantup.com/boxes/search?utf8=%E2%9C%93&sort=downloads&provider=&q=jborean93>`_ にアップロードされました。これらの画像がどのように作成されるかについての詳細は、GitHub リポジトリーで ``README`` ファイルを確認してください。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:38
msgid "Before you can get started, the following programs must be installed (please consult the Vagrant and VirtualBox documentation for installation instructions):"
msgstr "作業を開始する前に、以下のプログラムをインストールする必要があります (インストール方法は Vagrant および VirtualBox のドキュメントを参照してください)。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:41
msgid "Vagrant"
msgstr "Vagrant"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:42
msgid "VirtualBox"
msgstr "VirtualBox"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:45
msgid "Create a Windows server in a VM"
msgstr "仮想マシンで Windows サーバーを作成"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:47
msgid "To create a single Windows Server 2016 instance, run the following:"
msgstr "1 つの Windows Server 2016 インスタンスを作成するには、次のコマンドを実行します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:54
msgid "This will download the Vagrant box from Vagrant Cloud and add it to the local boxes on your host and then start up that instance in VirtualBox. When starting for the first time, the Windows VM will run through the sysprep process and then create a HTTP and HTTPS WinRM listener automatically. Vagrant will finish its process once the listeners are online, after which the VM can be used by Ansible."
msgstr "これにより、Vagrant Cloud から Vagrant ボックスをダウンロードし、ホストのローカルボックスに追加して、VirtualBox でそのインスタンスを起動します。初めて起動すると、Windows 仮想マシンが sysprep プロセスを介して実行し、HTTP および HTTPS WinRM リスナーを自動的に作成します。Vagrant は、リスナーがオンラインになるとプロセスを終了します。その後、Ansible で仮想マシンを使用できるようになります。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:61
msgid "Create an Ansible inventory"
msgstr "Ansible インベントリーの作成"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:63
msgid "The following Ansible inventory file can be used to connect to the newly created Windows VM:"
msgstr "以下の Ansible インベントリーファイルを使用して、新しく作成した Windows 仮想マシンに接続できます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:79
msgid "The port ``55986`` is automatically forwarded by Vagrant to the Windows host that was created, if this conflicts with an existing local port then Vagrant will automatically use another one at random and display show that in the output."
msgstr "ポート ``55986`` は、Vagrant によって作成された Windows ホストに自動的に転送されます。これが既存のローカルポートと競合する場合、Vagrant は自動的に別のポートをランダムに使用し、出力にそれを表示します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:84
msgid "The OS that is created is based on the image set. The following images can be used:"
msgstr "作成される OS はイメージセットに基づいています。次のイメージを使用できます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:87
msgid "`jborean93/WindowsServer2012 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2012>`_"
msgstr "`jborean93/WindowsServer2012 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2012>`_"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:88
msgid "`jborean93/WindowsServer2012R2 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2012R2>`_"
msgstr "`jborean93/WindowsServer2012R2 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2012R2>`_"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:89
msgid "`jborean93/WindowsServer2016 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2016>`_"
msgstr "`jborean93/WindowsServer2016 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2016>`_"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:90
msgid "`jborean93/WindowsServer2019 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2019>`_"
msgstr "`jborean93/WindowsServer2016 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2016>`_"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:91
msgid "`jborean93/WindowsServer2022 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2022>`_"
msgstr "`jborean93/WindowsServer2012R2 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2012R2>`_"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:93
msgid "When the host is online, it can accessible by RDP on ``127.0.0.1:3389`` but the port may differ depending if there was a conflict. To get rid of the host, run ``vagrant destroy --force`` and Vagrant will automatically remove the VM and any other files associated with that VM."
msgstr "ホストがオンラインになったら、``127.0.0.1:3389`` で RDP からアクセスできますが、競合があったかどうかによってポートが異なる場合があります。ホストを取り除くには、``vagrant destroy --force`` を実行すると、Vagrant が、仮想マシンとその仮想マシンに関連付けられたその他のファイルを自動的に削除します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:98
msgid "While this is useful when testing modules on a single Windows instance, these host won't work without modification with domain based modules. The Vagrantfile at `ansible-windows <https://github.com/jborean93/ansible-windows/tree/master/vagrant>`_ can be used to create a test domain environment to be used in Ansible. This repo contains three files which are used by both Ansible and Vagrant to create multiple Windows hosts in a domain environment. These files are:"
msgstr "これは、単一の Windows インスタンスでモジュールをテストする際に役立ちますが、これらのホストはドメインベースのモジュールで変更せずに動作しません。`ansible-windows <https://github.com/jborean93/ansible-windows/tree/master/vagrant>`_ の Vagrant を使用して、Ansible で使用するテストドメイン環境を作成できます。このリポジトリーには、Ansible と Vagrant で使用されている 3 つのファイルが含まれ、ドメイン環境で複数の Windows ホストを作成するのに使用できます。このファイルは、以下のようになります。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:105
msgid "``Vagrantfile``: The Vagrant file that reads the inventory setup of ``inventory.yml`` and provisions the hosts that are required"
msgstr "``Vagrantfile`` - ``inventory.yml`` のインベントリー設定を読み込んで、必要なホストをプロビジョニングする Vagrant ファイルです。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:106
msgid "``inventory.yml``: Contains the hosts that are required and other connection information such as IP addresses and forwarded ports"
msgstr "``inventory.yml`` - 必要なホストと、IP アドレスや転送ポートなどの他の接続情報が含まれています。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:107
msgid "``main.yml``: Ansible playbook called by Vagrant to provision the domain controller and join the child hosts to the domain"
msgstr "``main.yml`` - Vagrant に呼び出された Ansible Playbook は、ドメインコントローラーをプロビジョニングし、子ホストをドメインに参加させます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:109
msgid "By default, these files will create the following environment:"
msgstr "デフォルトでは、これらのファイルは以下の環境を作成します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:111
msgid "A single domain controller running on Windows Server 2016"
msgstr "Windows Server 2016 で実行しているドメインコントローラー 1 つ"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:112
msgid "Five child hosts for each major Windows Server version joined to that domain"
msgstr "ドメインに参加している各 Windows Server のメジャーバージョンの子ホスト 5 台"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:113
msgid "A domain with the DNS name ``domain.local``"
msgstr "DNS 名 ``domain.local`` を持つドメイン"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:114
msgid "A local administrator account on each host with the username ``vagrant`` and password ``vagrant``"
msgstr "各ホストのローカル管理者アカウント (ユーザー名 ``vagrant`` およびパスワード ``vagrant``)"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:115
msgid "A domain admin account ``vagrant-domain@domain.local`` with the password ``VagrantPass1``"
msgstr "パスワード ``VagrantPass1`` を含むドメイン管理者アカウント ``vagrant-domain@domain.local``"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:117
msgid "The domain name and accounts can be modified by changing the variables ``domain_*`` in the ``inventory.yml`` file if it is required. The inventory file can also be modified to provision more or less servers by changing the hosts that are defined under the ``domain_children`` key. The host variable ``ansible_host`` is the private IP that will be assigned to the VirtualBox host only network adapter while ``vagrant_box`` is the box that will be used to create the VM."
msgstr "ドメイン名およびアカウントを変更するには、必要な場合に ``inventory.yml`` ファイルの変数 ``domain_*`` を変更することで変更できます。インベントリーファイルは、``domain_children`` キーで定義されるホストを変更して、より少ないサーバーをプロビジョニングするように変更することもできます。ホスト変数 ``ansible_host`` は、VirtualBox ホストに割り当てられるプライベート IP で、ネットワークアダプターのみに割り当てられますが、``vagrant_box`` は仮想マシンの作成に使用するボックスです。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:126
msgid "Provisioning the environment"
msgstr "環境のプロビジョニング"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:128
msgid "To provision the environment as is, run the following:"
msgstr "環境をそのままプロビジョニングするには、次を実行します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:136
msgid "Vagrant provisions each host sequentially so this can take some time to complete. If any errors occur during the Ansible phase of setting up the domain, run ``vagrant provision`` to rerun just that step."
msgstr "Vagrant は各ホストを順番にプロビジョニングするため、完了するまでに時間がかかる場合があります。ドメイン設定の Ansible フェーズ中にエラーが発生した場合は、``vagrant provision`` を実行してそのステップだけを再実行します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:140
msgid "Unlike setting up a single Windows instance with Vagrant, these hosts can also be accessed using the IP address directly as well as through the forwarded ports. It is easier to access it over the host only network adapter as the normal protocol ports are used, for example RDP is still over ``3389``. In cases where the host cannot be resolved using the host only network IP, the following protocols can be access over ``127.0.0.1`` using these forwarded ports:"
msgstr "Vagrant で単一の Windows インスタンスをセットアップするのとは異なり、これらのホストは、転送されたポートを介してだけでなく、IP アドレスを使用して直接アクセスすることもできます。ホストのみのネットワークアダプターを使用してアクセスする方が、通常のプロトコルのポートが使用されるため簡単です。たとえば、RDP はまだ ``3389`` でで使用されます。ホストのみのネットワーク IP を使用してホストを解決できない場合、以下のプロトコルは、これらの転送されたポートを使用して ``127.0.0.1`` を介してアクセスできます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:147
msgid "``RDP``: 295xx"
msgstr "``RDP``: 295xx"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:148
msgid "``SSH``: 296xx"
msgstr "``SSH``: 296xx"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:149
msgid "``WinRM HTTP``: 297xx"
msgstr "``WinRM HTTP``: 297xx"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:150
msgid "``WinRM HTTPS``: 298xx"
msgstr "``WinRM HTTPS``: 298xx"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:151
msgid "``SMB``: 299xx"
msgstr "``SMB``: 299xx"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:153
msgid "Replace ``xx`` with the entry number in the inventory file where the domain controller started with ``00`` and is incremented from there. For example, in the default ``inventory.yml`` file, WinRM over HTTPS for ``SERVER2012R2`` is forwarded over port ``29804`` as it's the fourth entry in ``domain_children``."
msgstr "``xx`` を、ドメインコントローラーが ``00`` から開始したインベントリーファイルのエントリー番号に置換えます。値がインクリメントされていきます。たとえば、デフォルトでは、``domain_children`` の 4 番目のエントリーであるため、``inventory.yml`` ファイル (WinRM over HTTPS for ``SERVER2012R2``) がポート ``29804`` 経由で転送されます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:159
msgid "Windows new module development"
msgstr "Windows 新しいモジュール開発"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:161
msgid "When creating a new module there are a few things to keep in mind:"
msgstr "新しいモジュールを作成する際には、以下の点に留意してください。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:163
msgid "Module code is in Powershell (.ps1) files while the documentation is contained in Python (.py) files of the same name"
msgstr "モジュールのコードは Powershell (.ps1) ファイルにあり、ドキュメントは同じ名前の Python (.py) ファイルに含まれています。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:164
msgid "Avoid using ``Write-Host/Debug/Verbose/Error`` in the module and add what needs to be returned to the ``$module.Result`` variable"
msgstr "モジュールでは ``Write-Host/Debug/Verbose/Error`` を使用せず、``$module.Result`` 変数に返す必要のあるものを追加します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:165
msgid "To fail a module, call ``$module.FailJson(\"failure message here\")``, an Exception or ErrorRecord can be set to the second argument for a more descriptive error message"
msgstr "モジュールを失敗させるには、``$module.FailJson(\"failure message here\")`` を呼び出して、Exception または ErrorRecord を 2 番目の引数に設定して、より詳細なエラーメッセージを表示できます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:166
msgid "You can pass in the exception or ErrorRecord as a second argument to ``FailJson(\"failure\", $_)`` to get a more detailed output"
msgstr "例外または ErrorRecord を 2 つ目の引数として ``FailJson(\"failure\", $_)`` に渡すと、より詳細な出力を取得できます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:167
msgid "Most new modules require check mode and integration tests before they are merged into the main Ansible codebase"
msgstr "ほとんどの新規モジュールには、主要な Ansible コードベースにマージする前にチェックモードと統合テストが必要です。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:168
msgid "Avoid using try/catch statements over a large code block, rather use them for individual calls so the error message can be more descriptive"
msgstr "大規模なコードブロックで try/catch 文を使用しないようにし、個別の呼び出しに使用することで、エラーメッセージがより分かりやすくなるようにします。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:169
msgid "Try and catch specific exceptions when using try/catch statements"
msgstr "try/catch 文の使用時に特定の例外を試して捕え (キャッチし) ます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:170
msgid "Avoid using PSCustomObjects unless necessary"
msgstr "必要な場合を除き PSCustomObject は使用しないでください。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:171
msgid "Look for common functions in ``./lib/ansible/module_utils/powershell/`` and use the code there instead of duplicating work. These can be imported by adding the line ``#Requires -Module *`` where * is the filename to import, and will be automatically included with the module code sent to the Windows target when run via Ansible"
msgstr "重複する作業を行わないように、``./lib/ansible/module_utils/powershell/`` にある共通の関数を探して、そこにあるコードを使用してください。これらの関数は ``#Requires -Module *`` という行を追加することでインポートすることができます。* はインポートするファイル名で、Ansible を介して実行する場合に、自動的に Windows ターゲットに送信されたモジュールコードが含まれています。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:172
msgid "As well as PowerShell module utils, C# module utils are stored in ``./lib/ansible/module_utils/csharp/`` and are automatically imported in a module execution if the line ``#AnsibleRequires -CSharpUtil *`` is present"
msgstr "PowerShell モジュールユーティリティーの他に、C# モジュールユーティリティーが ``./lib/ansible/module_utils/csharp/`` に本され、``#AnsibleRequires -CSharpUtil *`` 行が存在する場合に、モジュール実行に自動的にインポートされます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:173
msgid "C# and PowerShell module utils achieve the same goal but C# allows a developer to implement low level tasks, such as calling the Win32 API, and can be faster in some cases"
msgstr "C# と PowerShell モジュールのユーティリティーは同じ目標を達成しますが、C# を使用すると、開発者は Win32 API の呼び出しなどの低レベルのタスクを実装でき、場合によってはより高速になります。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:174
msgid "Ensure the code runs under Powershell v3 and higher on Windows Server 2012 and higher; if higher minimum Powershell or OS versions are required, ensure the documentation reflects this clearly"
msgstr "このコードが Windows Server 2012 以降の Powershell v3 以降で動作することを確認してください。最小バージョンより新しい Powershell または OS が必要な場合は、ドキュメントにこの内容が明確に反映されていることを確認してください。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:175
msgid "Ansible runs modules under strictmode version 2.0. Be sure to test with that enabled by putting ``Set-StrictMode -Version 2.0`` at the top of your dev script"
msgstr "Ansible は、strictmode バージョン 2.0 でモジュールを実行します。必ず、開発スクリプトの冒頭に ``Set-StrictMode -Version 2.0`` と記述して、この機能を有効にしてテストしてください。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:176
msgid "Favor native Powershell cmdlets over executable calls if possible"
msgstr "可能であれば、実行可能な呼び出しよりも、ネイティブの Powershell コマンドレットを優先してください。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:177
msgid "Use the full cmdlet name instead of aliases, for example ``Remove-Item`` over ``rm``"
msgstr "エイリアスの代わりに完全なコマンドレット名を使用してください (例: ``rm`` ではなく ``Remove-Item`` を使用)。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:178
msgid "Use named parameters with cmdlets, for example ``Remove-Item -Path C:\\temp`` over ``Remove-Item C:\\temp``"
msgstr "コマンドレットで名前付きパラメーターを使用します (例： ``Remove-Item C:\\temp`` ではなく ``Remove-Item -Path C:\\temp`` を使用)。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:180
msgid "A very basic Powershell module `win_environment <https://github.com/ansible-collections/ansible.windows/blob/main/plugins/modules/win_environment.ps1>`_ incorporates best practices for Powershell modules. It demonstrates how to implement check-mode and diff-support, and also shows a warning to the user when a specific condition is met."
msgstr "非常に基本的な Powershell モジュール `win_environment <https://github.com/ansible-collections/ansible.windows/blob/main/plugins/modules/win_environment.ps1>`_ が、Powershell モジュールのベストプラクティスに組み込まれています。これは、check-mode および diff-support を実装する方法を示し、特定の条件が満たされるとユーザーに警告を表示します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:182
msgid "A slightly more advanced module is `win_uri <https://github.com/ansible-collections/ansible.windows/blob/main/plugins/modules/win_uri.ps1>`_ which additionally shows how to use different parameter types (bool, str, int, list, dict, path) and a selection of choices for parameters, how to fail a module and how to handle exceptions."
msgstr "もう少し高度なモジュールとしては `win_uri <https://github.com/ansible-collections/ansible.windows/blob/main/plugins/modules/win_uri.ps1>`_ がありますが、ここで、さまざまなパラメーター型 (bool、str、int、list、dict、path) の使用方法やパラメーターの選択方法、モジュールを失敗させる方法、例外の処理方法などを紹介しています。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:184
msgid "As part of the new ``AnsibleModule`` wrapper, the input parameters are defined and validated based on an argument spec. The following options can be set at the root level of the argument spec:"
msgstr "新しい ``AnsibleModule`` ラッパーの一部として、入力パラメーターは引数の仕様に基づいて定義および検証されます。以下のオプションは、引数仕様のルートレベルで設定できます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:187
msgid "``mutually_exclusive``: A list of lists, where the inner list contains module options that cannot be set together"
msgstr "``mutually_exclusive``: リストのリストで、内側のリストには一緒に設定できないモジュールオプションが含まれています。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:188
msgid "``no_log``: Stops the module from emitting any logs to the Windows Event log"
msgstr "``no_log``: モジュールが Windows イベントログにログを出力しないようにします。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:189
msgid "``options``: A dictionary where the key is the module option and the value is the spec for that option"
msgstr "``options``: キーがモジュールオプションで、値がそのオプションの仕様となるディクショナリーです。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:190
msgid "``required_by``: A dictionary where the option(s) specified by the value must be set if the option specified by the key is also set"
msgstr "``required_by``: キーで指定されたオプションが設定されている場合に、値で指定されたオプションも設定しなければならないディクショナリーです。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:194
msgid "``required_if``: A list of lists where the inner list contains 3 or 4 elements;"
msgstr "``required_if``: 内部リストに 3 つまたは 4 つの要素が含まれるリストの一覧"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:192
msgid "The first element is the module option to check the value against"
msgstr "最初の要素は、値を確認するモジュールオプションです。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:193
msgid "The second element is the value of the option specified by the first element, if matched then the required if check is run"
msgstr "2 つ目の要素は、1 つ目の要素によって指定されるオプションの値です。一致すると必須の if チェックが実行します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:194
msgid "The third element is a list of required module options when the above is matched"
msgstr "3 つ目の要素は、上記が一致した場合に必要なモジュールオプションのリストです。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:195
msgid "An optional fourth element is a boolean that states whether all module options in the third elements are required (default: ``$false``) or only one (``$true``)"
msgstr "4 番目の要素 (任意) は、3 番目の要素のモジュールオプションがすべて必要なのか (デフォルト: ``$false``)、1 つだけが必要なのか (``$true``) を示すブール値です。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:196
msgid "``required_one_of``: A list of lists, where the inner list contains module options where at least one must be set"
msgstr "``required_one_of``: 少なくとも 1 つは設定しなければならないモジュールオプションが含まれているリストが記載されるリストです。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:197
msgid "``required_together``: A list of lists, where the inner list contains module options that must be set together"
msgstr "``required_together``: 一緒に設定しなければならないモジュールオプションが含まれているリストが記載されるリストです。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:198
msgid "``supports_check_mode``: Whether the module supports check mode, by default this is ``$false``"
msgstr "``supports_check_mode``: モジュールがチェックモードに対応しているかどうか (デフォルトは ``$false``) を指定します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:200
msgid "The actual input options for a module are set within the ``options`` value as a dictionary. The keys of this dictionary are the module option names while the values are the spec of that module option. Each spec can have the following options set:"
msgstr "モジュールの実際の入力オプションは、ディクショナリーとなる ``options`` 値に設定されています。このディクショナリーのキーはモジュールオプション名であり、値はそのモジュールオプションの仕様です。各仕様には、次のオプションを設定できます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:204
msgid "``aliases``: A list of aliases for the module option"
msgstr "``aliases``: モジュールオプションのエイリアス一覧"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:205
msgid "``choices``: A list of valid values for the module option, if ``type=list`` then each list value is validated against the choices and not the list itself"
msgstr "``choices``: モジュールオプションの有効な値のリストです。``type=list`` の場合は、各リストの値が選択したものに対して検証され、リスト自体は検証されません。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:206
msgid "``default``: The default value for the module option if not set"
msgstr "``default``: モジュールオプションのデフォルト値 (設定されていない場合) です。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:207
msgid "``deprecated_aliases``: A list of hashtables that define aliases that are deprecated and the versions they will be removed in. Each entry must contain the keys ``name`` and ``collection_name`` with either ``version`` or ``date``"
msgstr "``deprecated_aliases``: 非推奨となるエイリアスと、そのエイリアスが削除されるバージョンを定義するハッシュテーブルの一覧。各エントリーには、``version`` または ``date`` がある ``name`` キーと ``collection_name`` が含まれている必要があります。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:208
msgid "``elements``: When ``type=list``, this sets the type of each list value, the values are the same as ``type``"
msgstr "``elements``: ``type=list`` の場合は、各リスト値のタイプが設定され、値は ``type`` と同じになります。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:209
msgid "``no_log``: Will sanitise the input value before being returned in the ``module_invocation`` return value"
msgstr "``no_log``: ``module_invocation`` の戻り値で返される前に入力値をサニタイズします。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:210
msgid "``removed_in_version``: States when a deprecated module option is to be removed, a warning is displayed to the end user if set"
msgstr "``removed_in_version``: 非推奨のモジュールオプションがいつ削除されるかを示します。これが設定されている場合は、エンドユーザーに警告が表示されます"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:211
msgid "``removed_at_date``: States the date (YYYY-MM-DD) when a deprecated module option will be removed, a warning is displayed to the end user if set"
msgstr "``removed_at_date``: 非推奨のモジュールオプションが削除される日付 (YYYY-MM-DD) を示します。これが設定されている場合は、エンドユーザーに警告が表示されます"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:212
msgid "``removed_from_collection``: States from which collection the deprecated module option will be removed; must be specified if one of ``removed_in_version`` and ``removed_at_date`` is specified"
msgstr "``removed_from_collection``: 非推奨のモジュールオプションを削除するコレクションの状態。``removed_in_version`` および ``removed_at_date`` のいずれかが指定されている場合は指定する必要があります。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:213
msgid "``required``: Will fail when the module option is not set"
msgstr "``required``: モジュールオプションが設定されていない場合は失敗します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:224
msgid "``type``: The type of the module option, if not set then it defaults to ``str``. The valid types are;"
msgstr "``type``: モジュールオプションのタイプです。設定されていない場合は、デフォルトで ``str`` に設定されます。有効なタイプは以下のとおりです。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:215
msgid "``bool``: A boolean value"
msgstr "``bool``: ブール値"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:216
msgid "``dict``: A dictionary value, if the input is a JSON or key=value string then it is converted to dictionary"
msgstr "``dict``: ディクショナリーの値。入力が JSON または key=value 文字列の場合は、ディクショナリーに変換されます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:217
msgid "``float``: A float or `Single <https://docs.microsoft.com/en-us/dotnet/api/system.single?view=netframework-4.7.2>`_ value"
msgstr "``float``: 浮動小数点または `Single <https://docs.microsoft.com/en-us/dotnet/api/system.single?view=netframework-4.7.2>`_ の値"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:218
msgid "``int``: An Int32 value"
msgstr "``int``: Int32 値"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:219
msgid "``json``: A string where the value is converted to a JSON string if the input is a dictionary"
msgstr "``json``: 入力がディクショナリーである場合に値が JSON 文字列に変換される文字列"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:220
msgid "``list``: A list of values, ``elements=<type>`` can convert the individual list value types if set. If ``elements=dict`` then ``options`` is defined, the values will be validated against the argument spec. When the input is a string then the string is split by ``,`` and any whitespace is trimmed"
msgstr "``list``: 値の一覧 (``elements=<type>``) が設定されている場合は、個々のリスト値タイプを変換できます。``elements=dict`` の場合は、``options`` が定義され、値は引数の仕様に対して検証されます。入力が文字列である場合、文字列は ``,`` で分割され、空白文字はすべてトリミングされます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:221
msgid "``path``: A string where values likes ``%TEMP%`` are expanded based on environment values. If the input value starts with ``\\\\?\\`` then no expansion is run"
msgstr "``path``: ``%TEMP%`` などの値が環境値に基づいて展開される文字列です。入力値が ``\\\\?\\`` で始まると、展開は実行されません。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:222
msgid "``raw``: No conversions occur on the value passed in by Ansible"
msgstr "``raw``: Ansible によって渡される値で変換が行われません。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:223
msgid "``sid``: Will convert Windows security identifier values or Windows account names to a `SecurityIdentifier <https://docs.microsoft.com/en-us/dotnet/api/system.security.principal.securityidentifier?view=netframework-4.7.2>`_ value"
msgstr "``sid``: Windows セキュリティー識別子の値または Windows アカウント名を `SecurityIdentifier <https://docs.microsoft.com/en-us/dotnet/api/system.security.principal.securityidentifier?view=netframework-4.7.2>`_ 値に変換します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:224
msgid "``str``: The value is converted to a string"
msgstr "``str``: この値は文字列に変換されます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:226
msgid "When ``type=dict``, or ``type=list`` and ``elements=dict``, the following keys can also be set for that module option:"
msgstr "``type=dict`` または ``type=list`` および ``elements=dict`` の場合は、そのモジュールオプションに以下のキーを設定することもできます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:228
msgid "``apply_defaults``: The value is based on the ``options`` spec defaults for that key if ``True`` and null if ``False``. Only valid when the module option is not defined by the user and ``type=dict``."
msgstr "``apply_defaults``: この値は、``True`` の場合はそのキーの ``options`` 仕様のデフォルトになり、``False`` の場合は null です。モジュールオプションがユーザーによって定義されておらず、``type=dict`` の場合に限り有効です。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:229
msgid "``mutually_exclusive``: Same as the root level ``mutually_exclusive`` but validated against the values in the sub dict"
msgstr "``mutually_exclusive``: ルートレベルの ``mutually_exclusive`` と同じですが、サブディクショナリーの値に対して検証されます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:230
msgid "``options``: Same as the root level ``options`` but contains the valid options for the sub option"
msgstr "``options``: ルートレベルの ``options`` と同じですが、サブオプションの有効なオプションが含まれています。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:231
msgid "``required_if``: Same as the root level ``required_if`` but validated against the values in the sub dict"
msgstr "``required_if``: ルートレベルの ``required_if`` と同じですが、サブディクショナリーの値に対して検証されます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:232
msgid "``required_by``: Same as the root level ``required_by`` but validated against the values in the sub dict"
msgstr "``required_by``: ルートレベルの ``required_by`` と同じですが、サブディクショナリーの値に対して検証されます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:233
msgid "``required_together``: Same as the root level ``required_together`` but validated against the values in the sub dict"
msgstr "``required_together``: ルートレベルの ``required_together`` と同じですが、サブディクショナリーの値に対して検証されます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:234
msgid "``required_one_of``: Same as the root level ``required_one_of`` but validated against the values in the sub dict"
msgstr "``required_one_of``: ルートレベルの ``required_one_of`` と同じですが、サブディクショナリーの値に対して検証されます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:236
msgid "A module type can also be a delegate function that converts the value to whatever is required by the module option. For example the following snippet shows how to create a custom type that creates a ``UInt64`` value:"
msgstr "モジュール型は、値をモジュールオプションで必要とされるものに変換するデリゲート関数にすることもできます。次のスニペットの例は、``UInt64`` 値を作成するカスタム型を作成する方法を示しています。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:246
msgid "When in doubt, look at some of the other core modules and see how things have been implemented there."
msgstr "不明な場合は、他のコアモジュールを見て、そこにどのように実装されているかを見てみましょう。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:249
msgid "Sometimes there are multiple ways that Windows offers to complete a task; this is the order to favor when writing modules:"
msgstr "Windows がタスクを完了させるために、複数の方法が提示されることがあります。モジュールを書くときに好ましい順序は以下のようになります。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:252
msgid "Native Powershell cmdlets like ``Remove-Item -Path C:\\temp -Recurse``"
msgstr "``Remove-Item -Path C:\\temp -Recurse`` などのネイティブの Powershell コマンドレッド"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:253
msgid ".NET classes like ``[System.IO.Path]::GetRandomFileName()``"
msgstr "``[System.IO.Path]::GetRandomFileName()`` などの .NET クラス"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:254
msgid "WMI objects through the ``New-CimInstance`` cmdlet"
msgstr "``New-CimInstance`` コマンドレッド経由の WMI オブジェクト"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:255
msgid "COM objects through ``New-Object -ComObject`` cmdlet"
msgstr "``New-Object -ComObject`` コマンドレッド経由の COM オブジェクト"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:256
msgid "Calls to native executables like ``Secedit.exe``"
msgstr "``Secedit.exe`` など、ネイティブ実行可能ファイルへの呼び出し"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:258
msgid "PowerShell modules support a small subset of the ``#Requires`` options built into PowerShell as well as some Ansible-specific requirements specified by ``#AnsibleRequires``. These statements can be placed at any point in the script, but are most commonly near the top. They are used to make it easier to state the requirements of the module without writing any of the checks. Each ``requires`` statement must be on its own line, but there can be multiple requires statements in one script."
msgstr "PowerShell モジュールは、PowerShell に組み込まれている ``#Requires`` オプションの小さなサブセットと、``#AnsibleRequires`` で指定されている Ansible 固有の要件をサポートしています。これらのステートメントは、スクリプトの任意の位置に配置できますが、最も一般的なのは先頭付近です。これらのステートメントは、チェック項目を記述することなく、モジュールの要件を簡単に記述するために使用されます。``requires`` ステートメントはそれぞれ 1 行に書かなければなりませんが、1 つのスクリプトに複数の requires ステートメントを記述することができます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:266
msgid "These are the checks that can be used within Ansible modules:"
msgstr "以下のチェックは、Ansible モジュール内で使用できます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:268
msgid "``#Requires -Module Ansible.ModuleUtils.<module_util>``: Added in Ansible 2.4, specifies a module_util to load in for the module execution."
msgstr "``#Requires -Module Ansible.ModuleUtils.<module_util>``: Ansible 2.4 で追加され、モジュール実行のために読み込むモジュールユーティリティーを指定します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:269
msgid "``#Requires -Version x.y``: Added in Ansible 2.5, specifies the version of PowerShell that is required by the module. The module will fail if this requirement is not met."
msgstr "``#Requires -Version x.y``: Ansible 2.5 で追加され、モジュールが必要とする PowerShell バージョンを指定します。この要件を満たしていない場合は失敗します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:270
msgid "``#AnsibleRequires -PowerShell <module_util>``: Added in Ansible 2.8, like ``#Requires -Module``, this specifies a module_util to load in for module execution."
msgstr "``#AnsibleRequires -PowerShell <module_util>``: Ansible 2.8 で追加されました。``#Requires -Module`` のように、Ansible 2.8 で追加され、モジュール実行のために読み込むモジュールユーティリティーを指定します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:271
msgid "``#AnsibleRequires -CSharpUtil <module_util>``: Added in Ansible 2.8, specifies a C# module_util to load in for the module execution."
msgstr "``#AnsibleRequires -CSharpUtil <module_util>``: Ansible 2.8 で追加され、モジュール実行のために読み込む C# モジュールユーティリティーを指定します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:272
msgid "``#AnsibleRequires -OSVersion x.y``: Added in Ansible 2.5, specifies the OS build version that is required by the module and will fail if this requirement is not met. The actual OS version is derived from ``[Environment]::OSVersion.Version``."
msgstr "``#AnsibleRequires -OSVersion x.y``: Ansible 2.5 で追加され、モジュールが必要とする OS ビルドバージョンを指定します。この要件を満たしていない場合は失敗します。実際の OS バージョンは ``[Environment]::OSVersion.Version`` から由来します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:273
msgid "``#AnsibleRequires -Become``: Added in Ansible 2.5, forces the exec runner to run the module with ``become``, which is primarily used to bypass WinRM restrictions. If ``ansible_become_user`` is not specified then the ``SYSTEM`` account is used instead."
msgstr "``#AnsibleRequires -Become``: Ansible 2.5 で追加され、exec ランナーが ``become`` でモジュールを強制的に実行します。これは主に WinRM の制限を回避するために使用されます。``ansible_become_user`` が指定されていない場合は、代わりに ``SYSTEM`` アカウントが使用されます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:275
msgid "The ``#AnsibleRequires -PowerShell`` and ``#AnsibleRequires -CSharpUtil`` support further features such as:"
msgstr "``#AnsibleRequires -PowerShell`` および ``#AnsibleRequires -CSharpUtil`` は、以下のような追加機能をサポートします。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:278
msgid "Importing a util contained in a collection (added in Ansible 2.9)"
msgstr "コレクションに含まれるユーティリティーのインポート (Ansible 2.9 で追加)"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:279
msgid "Importing a util by relative names (added in Ansible 2.10)"
msgstr "相対名によるユーティリティーのインポート (Ansible 2.10 で追加)"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:280
msgid "Specifying the util is optional by adding `-Optional` to the import declaration (added in Ansible 2.12)."
msgstr "オプションで、インポート宣言に `-Optional` を追加してユーティリティーを指定できます (Ansible 2.12 で追加)。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:283
msgid "See the below examples for more details:"
msgstr "詳細については、以下の例を参照してください。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:313
msgid "For optional require statements, it is up to the module code to then verify whether the util has been imported before trying to use it. This can be done by checking if a function or type provided by the util exists or not."
msgstr "オプションの require ステートメントでは、モジュールコードにより、ユーティリティーを使用する前にインポート済みであることを確認するかどうかが決定されます。これは、ユーティリティーによって提供された機能またはタイプが存在するか確認することで実行できます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:317
msgid "While both ``#Requires -Module`` and ``#AnsibleRequires -PowerShell`` can be used to load a PowerShell module it is recommended to use ``#AnsibleRequires``. This is because ``#AnsibleRequires`` supports collection module utils, imports by relative util names, and optional util imports."
msgstr "PowerShell は ``#Requires -Module`` と ``#AnsibleRequires -PowerShell`` の両方を使用してロードできますが、``#AnsibleRequires`` の使用が推奨されます。これは、``#AnsibleRequires`` はコレクションモジュールユーティリティー、相対ユーティリティー名によるインポート、および任意のユーティリティーのインポートをサポートするためです。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:322
msgid "C# module utils can reference other C# utils by adding the line ``using Ansible.<module_util>;`` to the top of the script with all the other using statements."
msgstr "C# モジュールユーティリティーは、すべてのステートメントを使用し、スクリプトの冒頭に ``using Ansible.<module_util>;`` 行を追加することで、他の C# ユーティリティーを参照できます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:328
msgid "Windows module utilities"
msgstr "Windows モジュールユーティリティー"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:330
msgid "Like Python modules, PowerShell modules also provide a number of module utilities that provide helper functions within PowerShell. These module_utils can be imported by adding the following line to a PowerShell module:"
msgstr "Python モジュールと同様に、PowerShell モジュールは、PowerShell でヘルパー関数を提供する多くのモジュールユーティリティーを提供します。これらのモジュールユーティリティーは、以下の行を PowerShell モジュールに追加してインポートできます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:338
msgid "This will import the module_util at ``./lib/ansible/module_utils/powershell/Ansible.ModuleUtils.Legacy.psm1`` and enable calling all of its functions. As of Ansible 2.8, Windows module utils can also be written in C# and stored at ``lib/ansible/module_utils/csharp``. These module_utils can be imported by adding the following line to a PowerShell module:"
msgstr "これにより、モジュールユーティリティーが ``./lib/ansible/module_utils/powershell/Ansible.ModuleUtils.Legacy.psm1`` でインポートされ、すべての関数の呼び出しが可能になります。Ansible 2.8 と同様に、Windows モジュールユーティリティーは C# でも記述でき、``lib/ansible/module_utils/csharp`` に保存されます。これらのモジュールユーティリティーは、PowerShell モジュールに以下の行を追加することでインポートできます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:348
msgid "This will import the module_util at ``./lib/ansible/module_utils/csharp/Ansible.Basic.cs`` and automatically load the types in the executing process. C# module utils can reference each other and be loaded together by adding the following line to the using statements at the top of the util:"
msgstr "これにより、``./lib/ansible/module_utils/csharp/Ansible.Basic.cs`` でモジュールユーティリティーがインポートされ、実行中のプロセスでタイプが自動的に読み込まれます。C# モジュールユーティリティーは相互に参照でき、次の行を、ユーティリティーの上部にある using ステートメントに追加して読み込むことができます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:357
msgid "There are special comments that can be set in a C# file for controlling the compilation parameters. The following comments can be added to the script;"
msgstr "コンパイルパラメーターを制御するために C# ファイルに設定できる特別なコメントがあります。以下のコメントをスクリプトに追加できます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:360
msgid "``//AssemblyReference -Name <assembly dll> [-CLR [Core|Framework]]``: The assembly DLL to reference during compilation, the optional ``-CLR`` flag can also be used to state whether to reference when running under .NET Core, Framework, or both (if omitted)"
msgstr "``//AssemblyReference -Name <assembly dll> [-CLR [Core|Framework]]``: コンパイル中に参照するアセンブリー DLL です。任意の ``-CLR`` フラグを使用して、.NET Core、Framework、またはその両方 (省略されている場合) で実行するときに参照するかどうかを表示することもできます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:361
msgid "``//NoWarn -Name <error id> [-CLR [Core|Framework]]``: A compiler warning ID to ignore when compiling the code, the optional ``-CLR`` works the same as above. A list of warnings can be found at `Compiler errors <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/index>`_"
msgstr "``//NoWarn -Name <error id> [-CLR [Core|Framework]]``: コードをコンパイルするときに無視するコンパイラ警告 ID で、任意の ``-CLR`` が上記と同じように機能します。警告のリストは、`コンパイラーエラー <https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/index>`_ で見つけることができます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:363
msgid "As well as this, the following pre-processor symbols are defined;"
msgstr "この他に、以下のプリプロセッサーシンボルも定義されています。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:365
msgid "``CORECLR``: This symbol is present when PowerShell is running through .NET Core"
msgstr "``CORECLR``: このシンボルは、PowerShell が .NET Core を介して実行している場合に表示されます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:366
msgid "``WINDOWS``: This symbol is present when PowerShell is running on Windows"
msgstr "``WINDOWS``: このシンボルは、PowerShell が Windows で実行している場合に表示されます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:367
msgid "``UNIX``: This symbol is present when PowerShell is running on Unix"
msgstr "``UNIX``: このシンボルは、PowerShell が Unix で実行している場合に表示されます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:369
msgid "A combination of these flags help to make a module util interoperable on both .NET Framework and .NET Core, here is an example of them in action:"
msgstr "これフラグの組み合わせは、.NET Framework と .NET Core の両方でモジュールユーティリティーを相互運用可能にするのに役立ちます。以下に、実際の動作例を示します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:390
msgid "The following is a list of module_utils that are packaged with Ansible and a general description of what they do:"
msgstr "以下に Ansible と一緒にパッケージ化されているモジュールユーティリティーのリストと、それらの機能の一般的な説明です。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:393
msgid "ArgvParser: Utility used to convert a list of arguments to an escaped string compliant with the Windows argument parsing rules."
msgstr "ArgvParser: 引数のリストを Windows の引数解析ルールに準拠しているエスケープされた文字列に変換するのに使用されるユーティリティー。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:394
msgid "CamelConversion: Utility used to convert camelCase strings/lists/dicts to snake_case."
msgstr "CamelConversion: camelCase strings/lists/dicts を snake_case に変換するのに使用されるユーティリティー。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:395
msgid "CommandUtil: Utility used to execute a Windows process and return the stdout/stderr and rc as separate objects."
msgstr "CommandUtil: Windows プロセスを実行し、stdout/stderr と rc を異なるオブジェクトとして返すために使用されるユーティリティー。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:396
msgid "FileUtil: Utility that expands on the ``Get-ChildItem`` and ``Test-Path`` to work with special files like ``C:\\pagefile.sys``."
msgstr "FileUtil: ``C:\\pagefile.sys`` のような特殊なファイルを扱うために ``Get-ChildItem`` および ``Test-Path`` を拡張するユーティリティー。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:397
msgid "Legacy: General definitions and helper utilities for Ansible module."
msgstr "Legacy: Ansible モジュールの一般的な定義およびヘルパーユーティリティー。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:398
msgid "LinkUtil: Utility to create, remove, and get information about symbolic links, junction points and hard inks."
msgstr "LinkUtil: シンボリックリンク、分岐点、ハードインクに関する情報を作成、削除、および取得するユーティリティー。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:399
msgid "SID: Utilities used to convert a user or group to a Windows SID and vice versa."
msgstr "SID: ユーザーやグループを Windows SID に変換したり、Windows SID をユーザーやグループに変換するのに使用するユーティリティー。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:401
msgid "For more details on any specific module utility and their requirements, please see the `Ansible module utilities source code <https://github.com/ansible/ansible/tree/devel/lib/ansible/module_utils/powershell>`_."
msgstr "特定のモジュールユーティリティーとその要件に関する詳細は、`Ansible モジュールユーティリティーのソースコード <https://github.com/ansible/ansible/tree/devel/lib/ansible/module_utils/powershell>`_ を参照してください。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:404
msgid "PowerShell module utilities can be stored outside of the standard Ansible distribution for use with custom modules. Custom module_utils are placed in a folder called ``module_utils`` located in the root folder of the playbook or role directory."
msgstr "PowerShell モジュールユーティリティーは、カスタムモジュールで使用する標準の Ansible ディストリビューション外に保存できます。カスタムのモジュールユーティリティーは、Playbook またはロールディレクトリーのルートディレクトリーにある ``module_utils`` と呼ばれるディレクトリーに配置されます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:409
msgid "C# module utilities can also be stored outside of the standard Ansible distribution for use with custom modules. Like PowerShell utils, these are stored in a folder called ``module_utils`` and the filename must end in the extension ``.cs``, start with ``Ansible.``  and be named after the namespace defined in the util."
msgstr "C# モジュールユーティリティーは、カスタムモジュールで使用するための標準の Ansible ディストリビューション外にも保存できます。PowerShellutils と同様、``module_utils`` ディレクトリーに格納され、ファイル名は拡張子 ``.cs`` で終わり、``Ansible.`` で始まる、ユーティリティーで定義された名前空間の後に名前を指定する必要があります。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:413
msgid "The below example is a role structure that contains two PowerShell custom module_utils called ``Ansible.ModuleUtils.ModuleUtil1``, ``Ansible.ModuleUtils.ModuleUtil2``, and a C# util containing the namespace ``Ansible.CustomUtil``::"
msgstr "次の例は、呼び出された 2 つの PowerShell のカスタムモジュールユーティリティー (``Ansible.ModuleUtils.ModuleUtil1``、``Ansible.ModuleUtils.ModuleUtil2``、および名前空間 ``Ansible.CustomUtil`` を含む C# ユーティリティー) を含むロール構造です。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:428
msgid "Each PowerShell module_util must contain at least one function that has been exported with ``Export-ModuleMember`` at the end of the file. For example"
msgstr "PowerShell の各モジュールユーティリティーには、ファイルの終わりに ``Export-ModuleMember`` でエクスポートされた関数が少なくとも 1 つ含まれている必要があります。以下に例を示します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:437
msgid "Exposing shared module options"
msgstr "共有モジュールオプションの公開"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:439
msgid "PowerShell module utils can easily expose common module options that a module can use when building its argument spec. This allows common features to be stored and maintained in one location and have those features used by multiple modules with minimal effort. Any new features or bugfixes added to one of these utils are then automatically used by the various modules that call that util."
msgstr "PowerShell モジュールユーティリティーは、引数仕様を構築する際にモジュールが使用できる共通のモジュールオプションを簡単に公開できます。これにより、共通の機能は 1 つの場所に保存および維持でき、最小限の作業で複数のモジュールによって使用される機能を利用できます。これらのユーティリティーのいずれかに追加された新機能またはバグ修正は、そのユーティリティーのいずれかを呼び出すさまざまなモジュールによって自動的に使用されます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:444
msgid "An example of this would be to have a module util that handles authentication and communication against an API This util can be used by multiple modules to expose a common set of module options like the API endpoint, username, password, timeout, cert validation, and so on without having to add those options to each module spec."
msgstr "この例としては、API に対する認証と通信を処理するモジュールユーティリティーがあります。このユーティリティーは、API エンドポイント、ユーザー名、パスワード、タイムアウト、認定検証などの共通のモジュールオプションセットを公開するため、各モジュール仕様にそれらのオプションを追加しなくても、複数のモジュールによって使用できます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:448
msgid "The standard convention for a module util that has a shared argument spec would have"
msgstr "共有引数仕様を持つモジュールユーティリティーの標準規則は次のようになります。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:451
msgid "A ``Get-<namespace.name.util name>Spec`` function that outputs the common spec for a module"
msgstr "モジュールの共通の仕様を出力する ``Get-<namespace.name.util name>Spec`` 関数"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:451
msgid "It is highly recommended to make this function name be unique to the module to avoid any conflicts with other utils that can be loaded"
msgstr "読み込みできる他のユーティリティーとの競合を避けるために、この関数名をモジュールに固有のものに強く推奨します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:452
msgid "The format of the output spec is a Hashtable in the same format as the ``$spec`` used for normal modules"
msgstr "出力仕様の形式は、通常のモジュールに使用される ``$spec`` と同じ形式のハッシュテーブルです。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:453
msgid "A function that takes in an ``AnsibleModule`` object called under the ``-Module`` parameter which it can use to get the shared options"
msgstr "``-Module`` パラメーター下で呼び出された ``AnsibleModule`` オブジェクトを取り入れた関数。これを使用して共有オプションを取得できます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:455
msgid "Because these options can be shared across various module it is highly recommended to keep the module option names and aliases in the shared spec as specific as they can be. For example do not have a util option called ``password``, rather you should prefix it with a unique name like ``acme_password``."
msgstr "これらのオプションは各種モジュール間で共有できるため、モジュールオプション名とエイリアスを、可能な限り具体的な仕様に維持することが高く推奨されます。たとえば、``password`` ユーティリティーオプションがありません。たとえば、``acme_password`` などの一意の名前でプレフィックスを付けるべきではありません。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:460
msgid "Failure to have a unique option name or alias can prevent the util being used by module that also use those names or aliases for its own options."
msgstr "一意のオプション名またはエイリアスがないと、モジュールがユーティリティーを使用できなくなり、モジュールがそれらの名前またはエイリアスを独自のオプションに使用する可能性があります。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:463
msgid "The following is an example module util called ``ServiceAuth.psm1`` in a collection that implements a common way for modules to authentication with a service."
msgstr "以下は、コレクションで ``ServiceAuth.psm1`` モジュールユーティリティーの例になります。このモジュールは、サービスを使用した認証に共通の方法を実装します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:519
msgid "For a module to take advantage of this common argument spec it can be set out like"
msgstr "モジュールがこの共通の引数仕様を利用できるようにするには、以下のように設定できます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:546
msgid "Options defined in the module spec will always have precedence over a util spec. Any list values under the same key in a util spec will be appended to the module spec for that same key. Dictionary values will add any keys that are missing from the module spec and merge any values that are lists or dictionaries. This is similar to how the doc fragment plugins work when extending module documentation."
msgstr "モジュール仕様に定義されているオプションは常にユーティリティー仕様よりも優先されます。ユーティリティー仕様の同じキー下のリスト値は、同じキーのモジュール仕様に追加されます。ディクショナリーの値は、モジュール仕様に不足している鍵を追加し、リストまたはディクショナリーである値をマージします。これは、モジュールドキュメントを拡張するときにドキュメントフラグメントプラグインがどのように機能するかと似ています。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:551
msgid "To document these shared util options for a module, create a doc fragment plugin that documents the options implemented by the module util and extend the module docs for every module that implements the util to include that fragment in its docs."
msgstr "モジュールのこれらの共有ユーティリティーオプションを文書化するには、モジュールユーティリティーにより実装されたオプションを文書化するドキュメントフラグメントプラグインを作成し、ユーティリティーを実装するすべてのモジュールのモジュールドキュメントを拡張して、そのフラグメントをドキュメントに含めます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:557
msgid "Windows playbook module testing"
msgstr "Windows Playbook モジュールのテスト"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:559
msgid "You can test a module with an Ansible playbook. For example:"
msgstr "以下のように、Ansible Playbook でモジュールをテストできます。以下に例を示します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:561
msgid "Create a playbook in any directory ``touch testmodule.yml``."
msgstr "任意のディレクトリーに Playbook を作成します (``touch testmodule.yml``)。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:562
msgid "Create an inventory file in the same directory ``touch hosts``."
msgstr "同じディレクトリー ``touch hosts`` にインベントリーファイルを作成します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:563
msgid "Populate the inventory file with the variables required to connect to a Windows host(s)."
msgstr "Windows ホストへの接続に必要な変数を指定してインベントリーファイルを設定します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:564
msgid "Add the following to the new playbook file::"
msgstr "以下を新しい Playbook ファイルに追加します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:574
msgid "Run the playbook ``ansible-playbook -i hosts testmodule.yml``"
msgstr "Playbook ``ansible-playbook -i hosts testmodule.yml`` を実行します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:576
msgid "This can be useful for seeing how Ansible runs with the new module end to end. Other possible ways to test the module are shown below."
msgstr "これは、Ansible が新しいモジュールでエンドツーエンドでどのように実行されるかを確認するのに役立ちます。モジュールをテストする他の可能な方法を以下に示します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:582
msgid "Windows debugging"
msgstr "Windows のデバッグ"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:584
msgid "Debugging a module currently can only be done on a Windows host. This can be useful when developing a new module or implementing bug fixes. These are some steps that need to be followed to set this up:"
msgstr "現在、モジュールのデバッグは Windows ホストでのみ実行できます。これは、新しいモジュールを開発したり、バグ修正を実装したりするときに役立ちます。これを設定するには、次の手順に従う必要があります。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:588
msgid "Copy the module script to the Windows server"
msgstr "モジュールスクリプトを Windows サーバーにコピーします。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:589
msgid "Copy the folders ``./lib/ansible/module_utils/powershell`` and ``./lib/ansible/module_utils/csharp`` to the same directory as the script above"
msgstr "``./lib/ansible/module_utils/powershell`` ディレクトリーと ``./lib/ansible/module_utils/csharp`` ディレクトリーを上記のスクリプトと同じディレクトリーにコピーします。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:590
msgid "Add an extra ``#`` to the start of any ``#Requires -Module`` lines in the module code, this is only required for any lines starting with ``#Requires -Module``"
msgstr "モジュールコードにあるすべての ``#Requires -Module`` 行の先頭に ``#`` を追加してください。これは、``#Requires -Module`` で始まる行にのみ必要です。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:591
msgid "Add the following to the start of the module script that was copied to the server:"
msgstr "以下を、サーバーにコピーされたモジュールスクリプトの先頭に追加します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:623
msgid "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:"
msgstr "モジュールに必要な場合は ``$complex_args`` にさらに引数を追加したり、その構造を持つ JSON ファイルでモジュールオプションを定義することもできます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:637
msgid "There are multiple IDEs that can be used to debug a Powershell script, two of the most popular ones are"
msgstr "Powershell スクリプトのデバッグに使用できる IDE が複数あり、以下の 2 つが最も一般的なものになります。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:640
msgid "`Powershell ISE`_"
msgstr "`Powershell ISE`_"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:641
msgid "`Visual Studio Code`_"
msgstr "`Visual Studio Code`_"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:646
msgid "To be able to view the arguments as passed by Ansible to the module follow these steps."
msgstr "Ansible がモジュールに渡した引数を表示するには、次の手順に従います。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:649
msgid "Prefix the Ansible command with :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1<ANSIBLE_KEEP_REMOTE_FILES>` to specify that Ansible should keep the exec files on the server."
msgstr "Ansible コマンドの前に :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1<ANSIBLE_KEEP_REMOTE_FILES>` を付けて、Ansible が exec ファイルをサーバ上に保持するように指定します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:650
msgid "Log onto the Windows server using the same user account that Ansible used to execute the module."
msgstr "Ansible がモジュールの実行に使用したのと同じユーザーアカウントを使用して Windows サーバーにログインします。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:651
msgid "Navigate to ``%TEMP%\\..``. It should contain a folder starting with ``ansible-tmp-``."
msgstr "``%TEMP%\\..`` に移動します。これには、``ansible-tmp-`` で始まるディレクトリーが含まれるはずです。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:652
msgid "Inside this folder, open the PowerShell script for the module."
msgstr "このディレクトリー内で、モジュールの PowerShell スクリプトを開きます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:653
msgid "In this script is a raw JSON script under ``$json_raw`` which contains the module arguments under ``module_args``. These args can be assigned manually to the ``$complex_args`` variable that is defined on your debug script or put in the ``args.json`` file."
msgstr "このスクリプトは、``$json_raw`` にある生の JSON スクリプトで、``module_args`` の下にモジュール引数が含まれています。これらの引数は、デバッグスクリプトで定義される ``$complex_args`` 変数に手動で割り当てたり、``args.json`` ファイルに置いたりできます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:657
msgid "Windows unit testing"
msgstr "Windows ユニットテスト"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:659
msgid "Currently there is no mechanism to run unit tests for Powershell modules under Ansible CI."
msgstr "現在、Ansible CI で Powershell モジュールのユニットテストを実行するメカニズムはありません。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:663
msgid "Windows integration testing"
msgstr "Windows 統合テスト"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:665
msgid "Integration tests for Ansible modules are typically written as Ansible roles. These test roles are located in ``./test/integration/targets``. You must first set up your testing environment, and configure a test inventory for Ansible to connect to."
msgstr "Ansible モジュールの統合テストは通常 Ansible ロールとして記述されます。これらのテストロールは ``./test/integration/targets`` にあります。まず、テスト環境を設定して、Ansible が接続できるようにテストインベントリーを設定する必要があります。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:669
msgid "In this example we will set up a test inventory to connect to two hosts and run the integration tests for win_stat:"
msgstr "この例では、2 つのホストに接続し、win_stat の統合テストを実行するためのテストインベントリーを設定します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:672
msgid "Run the command ``source ./hacking/env-setup`` to prepare environment."
msgstr "環境を準備するには、``source ./hacking/env-setup`` コマンドを実行します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:673
msgid "Create a copy of ``./test/integration/inventory.winrm.template`` and name it ``inventory.winrm``."
msgstr "``./test/integration/inventory.winrm.template`` のコピーを作成し、``inventory.winrm`` という名前を指定します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:674
msgid "Fill in entries under ``[windows]`` and set the required variables that are needed to connect to the host."
msgstr "``[windows]`` の下にエントリーを入力し、ホストへの接続に必要な変数を設定します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:675
msgid ":ref:`Install the required Python modules <windows_winrm>` to support WinRM and a configured authentication method."
msgstr "WinRM と、設定された認証方法をサポートするのに :ref:`必要な Python モジュールをインストール <windows_winrm>` します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:676
msgid "To execute the integration tests, run ``ansible-test windows-integration win_stat``; you can replace ``win_stat`` with the role you want to test."
msgstr "統合テストを実行するには、``ansible-test windows-integration win_stat`` を実行します。``win_stat`` は、テストするロールに置き換えることができます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:678
msgid "This will execute all the tests currently defined for that role. You can set the verbosity level using the ``-v`` argument just as you would with ansible-playbook."
msgstr "これにより、そのロールに対して現在定義されているすべてのテストが実行されます。ansible-playbook の場合と同じように、``-v`` 引数を使用して詳細レベルを設定できます。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:682
msgid "When developing tests for a new module, it is recommended to test a scenario once in check mode and twice not in check mode. This ensures that check mode does not make any changes but reports a change, as well as that the second run is idempotent and does not report changes. For example:"
msgstr "新しいモジュールのテストを開発するときは、シナリオをチェックモードで 1 回、チェックモード以外で 2 回テストすることが推奨されます。これにより、チェックモードでは変更は行われず、変更が報告されます。また、2 回目の実行は冪等であり、変更は報告されません。以下に例を示します。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:735
msgid "Windows communication and development support"
msgstr "Windows の通信および開発サポート"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:737
msgid "Join the ``#ansible-devel`` or ``#ansible-windows`` chat channels (using Matrix at ansible.im or using IRC at `irc.libera.chat <https://libera.chat/>`_) for discussions about Ansible development for Windows."
msgstr "``#ansible-devel`` または``#ansible-windows``チャットチャンネル（ansible.imでMatrixを使用、または`irc.libera.chat <https://libera.chat/>`でIRCを使用）に参加して、Windows向けのAnsible 開発に関する議論を行います。"

#: ../../rst/dev_guide/developing_modules_general_windows.rst:739
msgid "For questions and discussions pertaining to using the Ansible product, use the ``#ansible`` channel."
msgstr "Ansible 製品の使用に関する質問および貢献については、``#ansible`` チャンネルを使用します。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:5
msgid "Creating a new collection"
msgstr "新規コレクションの作成"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:7
msgid "Starting with Ansible 2.10, related modules should be developed in a collection. The Ansible core team and community compiled these module development tips and tricks to help companies developing Ansible modules for their products and users developing Ansible modules for third-party products. See :ref:`developing_collections` for a more detailed description of the collections format and additional development guidelines."
msgstr "Ansible 2.10 以降、関連するモジュールをコレクションで開発する必要があります。Ansible コアチームおよびコミュニティーは、これらのモジュール開発のヒントとコツをまとめて、自社製品用の Ansible モジュールを開発している企業や、サードパーティー製品用の Ansible モジュールを開発しているユーザーを支援します。コレクションの形式と追加の開発ガイドラインの詳細は、「:ref:`developing_collections`」を参照してください。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:15
msgid "Before you start coding"
msgstr "コーディングを開始する前に"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:17
msgid "This list of prerequisites is designed to help ensure that you develop high-quality modules that work well with ansible-core and provide a seamless user experience."
msgstr "この前提条件のリストは、ansible-core で適切に機能し、シームレスなユーザーエクスペリエンスを提供する高品質のモジュールを確実に開発できるように設計されています。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:19
msgid "Read though all the pages linked off :ref:`developing_modules_general`; paying particular focus to the :ref:`developing_modules_checklist`."
msgstr "「:ref:`developing_modules_general`」からリンクされているすべてのページを読みます。特に、「:ref:`developing_modules_checklist`」に注意してください。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:20
msgid "We encourage PEP 8 compliance. See :ref:`testing_pep8` for more information."
msgstr "PEP 8 コンプライアンスが推奨されます。詳細は「:ref:`testing_pep8`」を参照してください。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:21
msgid "We encourage supporting :ref:`Python 2.6+ and Python 3.5+ <developing_python_3>`."
msgstr ":ref:`Python 2.6 以降および Python 3.5 以降 <developing_python_3>` をサポートすることが推奨されます。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:22
msgid "Look at Ansible Galaxy and review the naming conventions in your functional area (such as cloud, networking, databases)."
msgstr "Ansible Galaxy を確認し、機能エリア (クラウド、ネットワーク、データベースなど) で命名規則を確認します。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:23
msgid "With great power comes great responsibility: Ansible collection maintainers have a duty to help keep content up to date and release collections they are responsible for regularly. As with all successful community projects, collection maintainers should keep a watchful eye for reported issues and contributions."
msgstr "大きな力には大きな責任が伴います。Ansible コレクションのメンテナーには、コンテンツを最新の状態に保ち、定期的に責任のあるコレクションをリリースするのを支援する義務があります。成功しているすべてのコミュニティープロジェクトと同様に、コレクションのメンテナーは、報告された問題や貢献に注意を払う必要があります。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:24
msgid "We strongly recommend unit and/or integration tests. Unit tests are especially valuable when external resources (such as cloud or network devices) are required. For more information see :ref:`developing_testing` and the `Testing Working Group <https://github.com/ansible/community/blob/main/meetings/README.md>`_."
msgstr "ユニットテストや統合テストが強く推奨されます。ユニットテストは、外部リソース (クラウドやネットワークデバイスなど) が必要な場合に特に役に立ちます。詳細については、「:ref:`developing_testing`」および「`Testing Working Group <https://github.com/ansible/community/blob/main/meetings/README.md>`_」を参照してください。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:28
msgid "Naming conventions"
msgstr "命名規則"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:30
msgid "Fully Qualified Collection Names (FQCNs) for plugins and modules include three elements:"
msgstr "プラグインおよびモジュール用の完全修飾コレクション名 (FQCN) には 3 つの要素があります。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:32
msgid "the Galaxy namespace, which generally represents the company or group"
msgstr "Galaxy 名前空間。通常、会社またはグループを表します。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:33
msgid "the collection name, which generally represents the product or OS"
msgstr "コレクション名。通常は製品または OS を表します。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:37
msgid "the plugin or module name"
msgstr "プラグインまたはモジュール名"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:35
msgid "always in lower case"
msgstr "常に小文字"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:36
msgid "words separated with an underscore (``_``) character"
msgstr "単語はアンダースコア (``_``) 文字で区切られます。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:37
msgid "singular, rather than plural, for example, ``command`` not ``commands``"
msgstr "複数形ではなく、単数形 (例: ``commands`` ではなく ``command``)"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:39
msgid "For example, ``community.mongodb.mongodb_linux`` or ``cisco.meraki.meraki_device``."
msgstr "たとえば、``community.mongodb.mongodb_linux`` または ``cisco.meraki.meraki_device`` です。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:41
msgid "It is convenient if the organization and repository names on GitHub (or elsewhere) match your namespace and collection names on Ansible Galaxy, but it is not required. The plugin names you select, however, are always the same in your code repository and in your collection artifact on Galaxy."
msgstr "GitHub (または別の場所) の組織とリポジトリー名が Ansible Galaxy の名前空間とコレクション名と一致する場合に便利ですが、必須ではありません。ただし、選択したプラグイン名は、コードリポジトリーと Galaxy のコレクションアーティファクトで常に同じです。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:44
msgid "Speak to us"
msgstr "お問い合わせ"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:46
msgid "Circulating your ideas before coding helps you adopt good practices and avoid common mistakes. After reading the \"Before you start coding\" section you should have a reasonable idea of the structure of your modules. Write a list of your proposed plugin and/or module names, with a short description of what each one does. Circulate that list on IRC or a mailing list so the Ansible community can review your ideas for consistency and familiarity. Names and functionality that are consistent, predictable, and familiar make your collection easier to use."
msgstr "コーディングの前にアイデアを出し合うことで、良い習慣を取り入れ、よくある間違いを避けることができます。「コーディングを始める前に」のセクションを読んだ後、モジュールの構造について妥当なアイデアがあるはずです。提案するプラグインやモジュールの名前のリストを書き、それぞれが何をするのかを簡単に説明してください。そのリストを、IRC やメーリングリストで共有して、Ansible コミュニティーが一貫性や親しみやすさの観点からアイデアを検討できるようにします。一貫性があり、予測可能で、親しみやすい名前や機能は、コレクションをより使いやすくします。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:51
msgid "Where to get support"
msgstr "サポートを受ける場所"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:53
msgid "Ansible has a thriving and knowledgeable community of module developers that is a great resource for getting your questions answered."
msgstr "Ansible には、活発で知識が豊富なモジュール開発者のコミュニティーがあり、質問に答えるための素晴らしいリソースとなっています。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:55
msgid "In the :ref:`ansible_community_guide` you can find how to:"
msgstr ":ref:`ansible_community_guide` で、以下の方法を見つけることができます。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:57
msgid "Subscribe to the Mailing Lists - We suggest \"Ansible Development List\" and \"Ansible Announce list\""
msgstr "メーリングリストをサブスクライブすること。「Ansible Development List」および「Ansible Announce list」をお勧めします。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:58
msgid "``#ansible-devel`` - We have found that communicating on the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat <https://libera.chat/>`_) works best for developers so we can have an interactive dialogue."
msgstr "``#ansible-devel`` - ``#ansible-devel``のチャットチャンネル（ansible.im でMatrixを使用、または`irc.libera.chat <https://libera.chat/>`でIRCを使用）での対話が開発者に最適なものであることが分かっています。したがって、インタラクティブな会話を行うことができます。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:59
msgid "Working group and other chat channel meetings - Join the various weekly meetings `meeting schedule and agenda page <https://github.com/ansible/community/blob/main/meetings/README.md>`_"
msgstr "ワーキンググループおよびその他のチャットチャンネルミーティング - さまざまな週間ミーティング (`meeting schedule and agenda page <https://github.com/ansible/community/blob/main/meetings/README.md>`_) に参加してください。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:62
msgid "Required files"
msgstr "必須ファイル"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:64
msgid "Your collection should include the following files to be usable:"
msgstr "コレクションには、使用可能な以下のファイルが含まれているはずです。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:66
msgid "an ``__init__.py`` file - An empty file to initialize namespace and allow Python to import the files. *Required*"
msgstr "``__init__.py`` ファイル - 名前空間を初期化し、Python がファイルをインポートできるようにする空のファイル。*必須*"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:67
msgid "at least one plugin, for example, ``/plugins/modules/$your_first_module.py``. *Required*"
msgstr "少なくとも 1 つのプラグイン (例: ``/plugins/modules/$your_first_module.py``)。*必須*"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:68
msgid "if needed, one or more ``/plugins/doc_fragments/$topic.py`` files - Code documentation, such as details regarding common arguments. *Optional*"
msgstr "必要な場合は、1 つ以上の ``/plugins/doc_fragments/$topic.py`` ファイル - 一般的な引数の詳細などのコードのドキュメント。*任意*"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:69
msgid "if needed, one or more ``/plugins/module_utils/$topic.py`` files - Code shared between more than one module, such as common arguments. *Optional*"
msgstr "必要な場合は、1 つ以上の ``/plugins/module_utils/$topic.py`` ファイル - 一般的な引数などの、複数のモジュール間で共有されるコード。*任意*"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:71
msgid "When you have these files ready, review the :ref:`developing_modules_checklist` again. If you are creating a new collection, you are responsible for all procedures related to your repository, including setting rules for contributions, finding reviewers, and testing and maintaining the code in your collection."
msgstr "これらのファイルの準備が整ったら、:ref:`developing_modules_checklist` を再度確認します。新しいコレクションを作成する場合は、貢献のルール設定、レビュー担当者の見つけ方、コレクションにおけるコードのテストおよび保守など、リポジトリーに関連するすべての手順を担当します。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:73
msgid "If you need help or advice, consider joining the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat <https://libera.chat/>`_). For more information, see :ref:`developing_in_groups_support` and :ref:`communication`."
msgstr "ヘルプやアドバイスが必要な場合は、``#ansible-devel`` チャットチャンネルへの参加をご検討ください（ansible.imでMatrixの使用または`irc.libera.chat <https://libera.chat/>`_でIRCを使用）。詳細については、:ref:`developing_in_groups_support` と:ref:`communication` を参照してください。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:76
msgid "New to git or GitHub"
msgstr "git または GitHub をはじめて使用する場合"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:78
msgid "We realize this may be your first use of Git or GitHub. The following guides may be of use:"
msgstr "ここでは、Git または GitHub を初めて使用するユーザーを対象としています。次のガイドが参考になるかもしれません。"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:80
msgid "`How to create a fork of ansible/ansible <https://help.github.com/articles/fork-a-repo/>`_"
msgstr "`How to create a fork of ansible/ansible <https://help.github.com/articles/fork-a-repo/>`_"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:81
msgid "`How to sync (update) your fork <https://help.github.com/articles/syncing-a-fork/>`_"
msgstr "`How to sync (update) your fork <https://help.github.com/articles/syncing-a-fork/>`_"

#: ../../rst/dev_guide/developing_modules_in_groups.rst:82
msgid "`How to create a Pull Request (PR) <https://help.github.com/articles/about-pull-requests/>`_"
msgstr "`How to create a Pull Request (PR) <https://help.github.com/articles/about-pull-requests/>`_"

#: ../../rst/dev_guide/developing_plugins.rst:6
msgid "Developing plugins"
msgstr "プラグインの開発"

#: ../../rst/dev_guide/developing_plugins.rst:11
msgid "Plugins augment Ansible's core functionality with logic and features that are accessible to all modules. Ansible collections include a number of handy plugins, and you can easily write your own. All plugins must:"
msgstr "プラグインは、すべてのモジュールがアクセスできるロジックおよび機能を使用して Ansible のコア機能を拡張します。Ansible コレクションには多くの便利なプラグインが含まれており、独自のプラグインを簡単に作成できます。すべてのプラグインでは、以下を行う必要があります。"

#: ../../rst/dev_guide/developing_plugins.rst:13
msgid "be written in Python"
msgstr "Python で書かれている。"

#: ../../rst/dev_guide/developing_plugins.rst:14
msgid "raise errors"
msgstr "エラーを発生させる。"

#: ../../rst/dev_guide/developing_plugins.rst:15
msgid "return strings in unicode"
msgstr "Unicode で文字列を返す。"

#: ../../rst/dev_guide/developing_plugins.rst:16
msgid "conform to Ansible's configuration and documentation standards"
msgstr "Ansible の設定およびドキュメントの標準仕様に準拠する。"

#: ../../rst/dev_guide/developing_plugins.rst:18
msgid "Once you've reviewed these general guidelines, you can skip to the particular type of plugin you want to develop."
msgstr "これらの一般的なガイドラインを確認したら、開発する特定のタイプのプラグインに進んでください。"

#: ../../rst/dev_guide/developing_plugins.rst:21
msgid "Writing plugins in Python"
msgstr "Python でのプラグインの作成"

#: ../../rst/dev_guide/developing_plugins.rst:23
msgid "You must write your plugin in Python so it can be loaded by the ``PluginLoader`` and returned as a Python object that any module can use. Since your plugin will execute on the controller, you must write it in a :ref:`compatible version of Python <control_node_requirements>`."
msgstr "``PluginLoader`` により読み込まれ、モジュールが使用できる Python オブジェクトとして返すには、Python でプラグインを作成する必要があります。プラグインはコントローラーで実行するため、:ref:`互換性のある Python バージョン <control_node_requirements>` で作成する必要があります。"

#: ../../rst/dev_guide/developing_plugins.rst:26
msgid "Raising errors"
msgstr "エラーの発生"

#: ../../rst/dev_guide/developing_plugins.rst:28
msgid "You should return errors encountered during plugin execution by raising ``AnsibleError()`` or a similar class with a message describing the error. When wrapping other exceptions into error messages, you should always use the ``to_native`` Ansible function to ensure proper string compatibility across Python versions:"
msgstr "プラグインの実行中に発生したエラーは、``AnsibleError()`` またはエラーを記述したメッセージのある同様のクラスを発生させて返す必要があります。他の例外をエラーメッセージにラップする場合は、Python のバージョン間で適切な文字列の互換性を確保するために、常に Ansible 関数の ``to_native`` を使用する必要があります。"

#: ../../rst/dev_guide/developing_plugins.rst:39
msgid "Since Ansible evaluates variables only when they are needed, filter and test plugins should propagate the exceptions ``jinja2.exceptions.UndefinedError`` and ``AnsibleUndefinedVariable`` to ensure undefined variables are only fatal when necessary."
msgstr "Ansibleは必要なときにのみ変数を評価するので、未定義の変数が必要なときにのみ致命的な問題を起こすように、フィルターやテストプラグインは、例外``jinja2.exceptions.UndefinedError`` と``AnsibleUndefinedVariable`` を伝播させる必要があります。"

#: ../../rst/dev_guide/developing_plugins.rst:41
msgid "Check the different `AnsibleError objects <https://github.com/ansible/ansible/blob/devel/lib/ansible/errors/__init__.py>`_ and see which one applies best to your situation. Check the section on the specific plugin type you're developing for type-specific error handling details."
msgstr "さまざまな`AnsibleError objects <https://github.com/ansible/ansible/blob/devel/lib/ansible/errors/__init__.py>`_ をチェックして、どれが自分の状況に最も適しているかを確認してください。開発している特定のプライグインタイプに固有のエラー処理の詳細については、そのタイプのセクションを確認してください。"

#: ../../rst/dev_guide/developing_plugins.rst:45
msgid "String encoding"
msgstr "文字列エンコーディング"

#: ../../rst/dev_guide/developing_plugins.rst:47
msgid "You must convert any strings returned by your plugin into Python's unicode type. Converting to unicode ensures that these strings can run through Jinja2. To convert strings:"
msgstr "プラグインによって返される文字列は、Python の Unicode タイプに変換する必要があります。Unicode に変換すると、これらの文字列が Jinja2 を介して実行できるようになります。文字列を変換するには、次を実行します。"

#: ../../rst/dev_guide/developing_plugins.rst:55
msgid "Plugin configuration & documentation standards"
msgstr "プラグインの設定およびドキュメントの標準仕様"

#: ../../rst/dev_guide/developing_plugins.rst:57
msgid "To define configurable options for your plugin, describe them in the ``DOCUMENTATION`` section of the python file. Callback and connection plugins have declared configuration requirements this way since Ansible version 2.4; most plugin types now do the same. This approach ensures that the documentation of your plugin's options will always be correct and up-to-date. To add a configurable option to your plugin, define it in this format:"
msgstr "プラグインの設定可能なオプションを定義するには、python ファイルの ``DOCUMENTATION`` セクションに記述します。コールバックおよび connection プラグインは、Ansible バージョン 2.4 以降、この方法で設定要件を宣言します。現在、ほとんどのプラグインタイプが同じように動作するようになりました。この方法により、プラグインのオプションのドキュメントが常に正確で最新の状態になります。設定可能なオプションをプラグインに追加するには、以下の形式で定義します。"

#: ../../rst/dev_guide/developing_plugins.rst:78
msgid "To access the configuration settings in your plugin, use ``self.get_option(<option_name>)``. For the plugin types (such as 'become', 'cache', 'callback', 'cliconf', 'connection', 'httpapi', 'inventory', 'lookup', 'netconf', 'shell', and 'vars') that support embedded documentation, the controller pre-populates the settings. If you need to populate settings explicitly, use a ``self.set_options()`` call."
msgstr "プラグインの構成設定にアクセスするには、``self.get_option(<option_name>)``を使用します。組み込まれたドキュメントをサポートするプラグインタイプ(例：'become'、'cache'、'callback'、'cliconf'、'connection'、'httpapi'、'inventory'、'lookup'、'netconf'、'shell'、および'vars')については、コントローラーが設定を事前に設定します。明示的に設定を設定する必要がある場合は、``self.set_options()`` の呼び出しを使用してください。"

#: ../../rst/dev_guide/developing_plugins.rst:80
msgid "Configuration sources follow the precedence rules for values in Ansible. When there are multiple values from the same category, the value defined last takes precedence. For example, in the above configuration block, if both ``name_of_ansible_var`` and ``name_of_second_var`` are defined, the value of the ``option_name`` option will be the value of ``name_of_second_var``. Refer to :ref:`general_precedence_rules` for further information."
msgstr "設定ソースは、Ansibleの値の優先順位ルールに従います。同じカテゴリからの値が複数ある場合、最後に定義された値が優先されます。たとえば、上記の設定ブロックでは、``name_of_ansible_var`` と``name_of_second_var`` の両方が定義されている場合、``option_name`` オプションの値は``name_of_second_var`` の値になります。詳細は:ref:`general_precedence_rules` を参照してください。"

#: ../../rst/dev_guide/developing_plugins.rst:82
msgid "Plugins that support embedded documentation (see :ref:`ansible-doc` for the list) should include well-formed doc strings. If you inherit from a plugin, you must document the options it takes, either via a documentation fragment or as a copy. See :ref:`module_documenting` for more information on correct documentation. Thorough documentation is a good idea even if you're developing a plugin for local use."
msgstr "埋め込みドキュメントをサポートするプラグイン (:ref:`ansible-doc` リストの場合を参照) は、適切に構築されたドキュメント文字列を含める必要があります。プラグインから継承する場合は、ドキュメントフラグメントを介して、またはコピーとして、必要なオプションを記述する必要があります。正しいドキュメントに関する詳細は、「:ref:`module_documenting`」を参照してください。ローカルで使用するプラグインを開発している場合でも、完全なドキュメントを作成することが推奨されます。"

#: ../../rst/dev_guide/developing_plugins.rst:85
msgid "Developing particular plugin types"
msgstr "特定のプラグインタイプの開発"

#: ../../rst/dev_guide/developing_plugins.rst:90
#: ../../rst/dev_guide/developing_program_flow_modules.rst:24
msgid "Action plugins"
msgstr "action プラグイン"

#: ../../rst/dev_guide/developing_plugins.rst:92
msgid "Action plugins let you integrate local processing and local data with module functionality."
msgstr "action プラグインを使用すると、ローカル処理とローカルデータをモジュール機能に統合できます。"

#: ../../rst/dev_guide/developing_plugins.rst:94
msgid "To create an action plugin, create a new class with the Base(ActionBase) class as the parent:"
msgstr "action プラグインを作成するには、Base(ActionBase) クラスを親として新しいクラスを作成します。"

#: ../../rst/dev_guide/developing_plugins.rst:103
msgid "From there, execute the module using the ``_execute_module`` method to call the original module. After successful execution of the module, you can modify the module return data."
msgstr "そこから、``_execute_module`` メソッドを使用してモジュールを実行して、元のモジュールを呼び出します。モジュールの実行に成功すると、モジュールの戻り値データを変更できます。"

#: ../../rst/dev_guide/developing_plugins.rst:113
msgid "For example, if you wanted to check the time difference between your Ansible controller and your target machine(s), you could write an action plugin to check the local time and compare it to the return data from Ansible's ``setup`` module:"
msgstr "たとえば、Ansible コントローラーとターゲットマシン間の時間差を確認する場合は、action プラグインを作成してローカルタイムを確認し、それを Ansible の ``setup`` モジュールから返されるデータと比較できます。"

#: ../../rst/dev_guide/developing_plugins.rst:150
msgid "This code checks the time on the controller, captures the date and time for the remote machine using the ``setup`` module, and calculates the difference between the captured time and the local time, returning the time delta in days, seconds and microseconds."
msgstr "このコードはコントローラーの時間を確認し、``setup`` モジュールを使用してリモートマシンの日時を取得し、取得した時間とローカル時間の差異を算出し、その時間差を日数、秒、およびマイクロ秒で返します。"

#: ../../rst/dev_guide/developing_plugins.rst:153
msgid "For practical examples of action plugins, see the source code for the `action plugins included with Ansible Core <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/action>`_"
msgstr "action プラグインの実際の例は、`Ansible Core に同梱される action プラグイン <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/action>`_ のソースコードを参照してください。"

#: ../../rst/dev_guide/developing_plugins.rst:159
msgid "Cache plugins"
msgstr "Cache プラグイン"

#: ../../rst/dev_guide/developing_plugins.rst:161
msgid "Cache plugins store gathered facts and data retrieved by inventory plugins."
msgstr "dache プラグインは、inventory プラグインによって取得されるファクトおよびデータを格納します。"

#: ../../rst/dev_guide/developing_plugins.rst:163
msgid "Import cache plugins using the cache_loader so you can use ``self.set_options()`` and ``self.get_option(<option_name>)``. If you import a cache plugin directly in the code base, you can only access options via ``ansible.constants``, and you break the cache plugin's ability to be used by an inventory plugin."
msgstr "``self.set_options()`` および ``self.get_option(<option_name>)`` を使用できる cache_loader を使用する cache プラグインをインポートします。コードベースで cache プラグインを直接インポートする場合は、``ansible.constants`` からのみオプションにアクセスでき、inventory プラグインによって使用される cache プラグインの機能が壊れます。"

#: ../../rst/dev_guide/developing_plugins.rst:171
msgid "There are two base classes for cache plugins, ``BaseCacheModule`` for database-backed caches, and ``BaseCacheFileModule`` for file-backed caches."
msgstr "cache プラグインには、2 つのベースクラス (データベースベースのバックアップ用のキャッシュの場合は ``BaseCacheModule``、ファイルのバックアップ用のキャッシュの場合は ``BaseCacheFileModule``) があります。"

#: ../../rst/dev_guide/developing_plugins.rst:173
msgid "To create a cache plugin, start by creating a new ``CacheModule`` class with the appropriate base class. If you're creating a plugin using an ``__init__`` method you should initialize the base class with any provided args and kwargs to be compatible with inventory plugin cache options. The base class calls ``self.set_options(direct=kwargs)``. After the base class ``__init__`` method is called ``self.get_option(<option_name>)`` should be used to access cache options."
msgstr "キャッシュプラグインを作成するには、適切なベースクラスで新しい ``CacheModule`` クラスを作成して開始します。``__init__`` メソッドを使用してプラグインを作成する場合は、指定された arg および kwarg でベースクラスを初期化し、インベントリープラグインキャッシュオプションと互換性がある必要があります。ベースクラスは ``self.set_options(direct=kwargs)`` を呼び出します。ベースクラス ``__init__`` メソッドが呼び出されると、``self.get_option(<option_name>)`` を使用して、キャッシュオプションにアクセスする必要があります。"

#: ../../rst/dev_guide/developing_plugins.rst:175
msgid "New cache plugins should take the options ``_uri``, ``_prefix``, and ``_timeout`` to be consistent with existing cache plugins."
msgstr "新しい cache プラグインは、既存の cache プラグインとの整合性を保つために、``_uri`` オプション、``_prefix`` オプション、および ``_timeout`` オプションを使用する必要があります。"

#: ../../rst/dev_guide/developing_plugins.rst:188
msgid "If you use the ``BaseCacheModule``, you must implement the methods ``get``, ``contains``, ``keys``, ``set``, ``delete``, ``flush``, and ``copy``. The ``contains`` method should return a boolean that indicates if the key exists and has not expired. Unlike file-based caches, the ``get`` method does not raise a KeyError if the cache has expired."
msgstr "``BaseCacheModule`` を使用する場合は、メソッド ``get``、``contains``、``keys``、``set``、``delete``、``flush``、および ``copy`` を実装する必要があります。``contains`` メソッドは、キーが存在し、有効期限が切れていないことを示すブール値を返すはずです。ファイルベースのキャッシュとは異なり、キャッシュの有効期限が切れると、``get`` メソッドによって KeyError は発生しません。"

#: ../../rst/dev_guide/developing_plugins.rst:190
msgid "If you use the ``BaseFileCacheModule``, you must implement ``_load`` and ``_dump`` methods that will be called from the base class methods ``get`` and ``set``."
msgstr "``BaseFileCacheModule`` を使用する場合は、ベースクラスメソッド ``get`` および ``set`` から呼び出される ``_load`` メソッドおよび ``_dump`` メソッドを実装する必要があります。"

#: ../../rst/dev_guide/developing_plugins.rst:192
msgid "If your cache plugin stores JSON, use ``AnsibleJSONEncoder`` in the ``_dump`` or ``set`` method  and ``AnsibleJSONDecoder`` in the ``_load`` or ``get`` method."
msgstr "キャッシュプラグインに JSON が保存されている場合は、``_dump`` メソッドまたは ``set`` メソッドの ``AnsibleJSONEncoder`` と、``_load`` メソッドまたは``get`` メソッドの ``AnsibleJSONDecoder`` を使用します。"

#: ../../rst/dev_guide/developing_plugins.rst:194
msgid "For example cache plugins, see the source code for the `cache plugins included with Ansible Core <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/cache>`_."
msgstr "cache プラグインの例は、`Ansible Core に同梱される cache プラグイン <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/cache>`_ のソースコードを参照してください。"

#: ../../rst/dev_guide/developing_plugins.rst:199
msgid "Callback plugins"
msgstr "callback プラグイン"

#: ../../rst/dev_guide/developing_plugins.rst:201
msgid "Callback plugins add new behaviors to Ansible when responding to events. By default, callback plugins control most of the output you see when running the command line programs."
msgstr "callback プラグインは、イベントに応答する際に新しい動作を Ansible に追加します。デフォルトでは、callback プラグインは、コマンドラインプログラムの実行時に表示されるほとんどの出力を制御します。"

#: ../../rst/dev_guide/developing_plugins.rst:203
msgid "To create a callback plugin, create a new class with the Base(Callbacks) class as the parent:"
msgstr "callback プラグインを作成するには、Base(Callbacks) クラスを親として使用して新規クラスを作成します。"

#: ../../rst/dev_guide/developing_plugins.rst:212
msgid "From there, override the specific methods from the CallbackBase that you want to provide a callback for. For plugins intended for use with Ansible version 2.0 and later, you should only override methods that start with ``v2``. For a complete list of methods that you can override, please see ``__init__.py`` in the `lib/ansible/plugins/callback <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/callback>`_ directory."
msgstr "そこから、コールバックを提供する CallbackBase から特定のメソッドを上書きします。Ansible バージョン 2.0 以降で使用するプラグインでは、``v2`` で始まる方法のみを上書きしてください。上書きできるメソッドの完全なリストは、`lib/ansible/plugins/callback <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/callback>`_ ディレクトリーの ``__init__.py`` を参照してください。"

#: ../../rst/dev_guide/developing_plugins.rst:217
msgid "The following is a modified example of how Ansible's timer plugin is implemented, but with an extra option so you can see how configuration works in Ansible version 2.4 and later:"
msgstr "以下は、Ansible の timer プラグインの実装方法の変更例です。ただし、追加のオプションを使用すると、Ansible バージョン 2.4 以降で構成がどのように機能するかを確認できます。"

#: ../../rst/dev_guide/developing_plugins.rst:286
msgid "Note that the ``CALLBACK_VERSION`` and ``CALLBACK_NAME`` definitions are required for properly functioning plugins for Ansible version 2.0 and later. ``CALLBACK_TYPE`` is mostly needed to distinguish 'stdout' plugins from the rest, since you can only load one plugin that writes to stdout."
msgstr "``CALLBACK_VERSION`` および ``CALLBACK_NAME`` の定義は、Ansible バージョン 2.0 以降のプラグインが正しく機能するために必要であることに注意してください。``CALLBACK_TYPE`` は、標準出力 (stdout) に書き込むプラグインを 1 つだけ読み込むことができるため、ほとんどの「stdout」プラグインをその他のものと区別するために必要です。"

#: ../../rst/dev_guide/developing_plugins.rst:288
msgid "For example callback plugins, see the source code for the `callback plugins included with Ansible Core <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/callback>`_"
msgstr "callback プラグインの例は、`Ansible Core に同梱される callback プラグイン <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/callback>`_ のソースコードを参照してください。"

#: ../../rst/dev_guide/developing_plugins.rst:290
msgid "New in ansible-core 2.11, callback plugins are notified (via ``v2_playbook_on_task_start``) of :ref:`meta<meta_module>` tasks. By default, only explicit ``meta`` tasks that users list in their plays are sent to callbacks."
msgstr "ansible-core 2.11 の新機能として、:ref:`meta<meta_module>` タスクのコールバックプラグインが (``v2_playbook_on_task_start`` を介して) 通知されます。デフォルトでは、プレイに追加する明示的な ``meta`` タスクのみが、コールバックに送信されます。"

#: ../../rst/dev_guide/developing_plugins.rst:292
msgid "There are also some tasks which are generated internally and implicitly at various points in execution. Callback plugins can opt-in to receiving these implicit tasks as well, by setting ``self.wants_implicit_tasks = True``. Any ``Task`` object received by a callback hook will have an ``.implicit`` attribute, which can be consulted to determine whether the ``Task`` originated from within Ansible, or explicitly by the user."
msgstr "実行のさまざまな時点で、内部的および暗黙的に生成されるタスクもいくつかあります。callback プラグインは、``self.wants_implicit_tasks = True`` を設定することにより、これらの暗黙的なタスクを受け取ることをオプトインできます。コールバックフックによって受信した ``Task`` オブジェクトには、``.implicit`` 属性があります。これを参照して、``Task`` が Ansible 内から、またはユーザーによって明示的に発信されたかどうかを決めるために参照します。"

#: ../../rst/dev_guide/developing_plugins.rst:297
msgid "Connection plugins"
msgstr "connection プラグイン"

#: ../../rst/dev_guide/developing_plugins.rst:299
msgid "Connection plugins allow Ansible to connect to the target hosts so it can execute tasks on them. Ansible ships with many connection plugins, but only one can be used per host at a time. The most commonly used connection plugins are the ``paramiko`` SSH, native ssh (just called ``ssh``), and ``local`` connection types.  All of these can be used in playbooks and with ``/usr/bin/ansible`` to connect to remote machines."
msgstr "connection プラグインにより、Ansible はターゲットホストに接続してそのホストにあるタスクを実行できるようにします。Ansible には多くの connection プラグインが同梱されていますが、一度に使用できるのは 1 つのみとなります。最も一般的に使用される connection プラグインは、``paramiko`` SSH、ネイティブ ssh (単に ``ssh`` と呼ばれる)、および ``local`` 接続タイプです。これらはすべて Playbook で使用され、``/usr/bin/ansible`` を使用してリモートマシンに接続します。"

#: ../../rst/dev_guide/developing_plugins.rst:301
msgid "Ansible version 2.1 introduced the ``smart`` connection plugin. The ``smart`` connection type allows Ansible to automatically select either the ``paramiko`` or ``openssh`` connection plugin based on system capabilities, or the ``ssh`` connection plugin if OpenSSH supports ControlPersist."
msgstr "Ansible バージョン 2.1 では、``smart`` connection プラグインが導入されます。``smart`` 接続タイプにより、Ansible は、システム機能に基づいて、``paramiko`` または ``openssh`` connection プラグインのいずれかを自動的に選択できますが、OpenSSH が ControlPersist に対応している場合は connetion プラグイン ``ssh`` を選択します。"

#: ../../rst/dev_guide/developing_plugins.rst:303
msgid "To create a new connection plugin (for example, to support SNMP, Message bus, or other transports), copy the format of one of the existing connection plugins and drop it into ``connection`` directory on your :ref:`local plugin path <local_plugins>`."
msgstr "新しい connetion プラグイン (SNMP、メッセージバス、またはその他のトランスポートをサポートする場合など) を作成するには、既存の connetion プラグインのいずれかの形式をコピーして、:ref:`ローカルプラグインパス <local_plugins>` にある ``connection`` ディレクトリーに置きます。"

#: ../../rst/dev_guide/developing_plugins.rst:305
msgid "Connection plugins can support common options (such as the ``--timeout`` flag) by defining an entry in the documentation for the attribute name (in this case ``timeout``). If the common option has a non-null default, the plugin should define the same default since a different default would be ignored."
msgstr "connection プラグインは、属性名 (ここでは ``timeout``) のドキュメントでエントリーを定義することで、一般的なオプション (``--timeout`` フラグなど) をサポートします。一般的なオプションには null 以外のデフォルトがある場合、別のデフォルトは無視されるため、プラグインは同じデフォルトを定義する必要があります。"

#: ../../rst/dev_guide/developing_plugins.rst:307
msgid "For example connection plugins, see the source code for the `connection plugins included with Ansible Core <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/connection>`_."
msgstr "選択プラグインの例は、`Ansible Core に同梱される接続プラグイン <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/connection>`_ のソースコードを参照してください。"

#: ../../rst/dev_guide/developing_plugins.rst:312
msgid "Filter plugins"
msgstr "filter プラグイン"

#: ../../rst/dev_guide/developing_plugins.rst:314
msgid "Filter plugins manipulate data. They are a feature of Jinja2 and are also available in Jinja2 templates used by the ``template`` module. As with all plugins, they can be easily extended, but instead of having a file for each one you can have several per file. Most of the filter plugins shipped with Ansible reside in a ``core.py``."
msgstr "filter プラグインはデータを操作します。これらは Jinja2 の機能であり、``template`` モジュールが使用する Jinja2 テンプレートで利用できます。すべてのプラグインと同様に、プラグインは簡単に拡張できますが、プラグインごとにファイルを作成する代わりに、ファイルごとに複数のプラグインを作成できます。Ansible に同梱されているフィルタープラグインのほとんどは、``core.py`` にあります。"

#: ../../rst/dev_guide/developing_plugins.rst:316
msgid "Filter plugins do not use the standard configuration and documentation system described above."
msgstr "filter プラグインは、上記の標準設定およびドキュメントシステムを使用しません。"

#: ../../rst/dev_guide/developing_plugins.rst:318
msgid "Since Ansible evaluates variables only when they are needed, filter plugins should propagate the exceptions ``jinja2.exceptions.UndefinedError`` and ``AnsibleUndefinedVariable`` to ensure undefined variables are only fatal when necessary."
msgstr "Ansibleは必要なときにのみ変数を評価するので、未定義の変数が必要なときにのみ致命的な問題を起こすように、フィルタープラグインは、例外``jinja2.exceptions.UndefinedError`` と``AnsibleUndefinedVariable`` を伝播させる必要があります。"

#: ../../rst/dev_guide/developing_plugins.rst:329
msgid "For example filter plugins, see the source code for the `filter plugins included with Ansible Core <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/filter>`_."
msgstr "filter プラグインの例は、`Ansible Core に同梱される filter プラグイン <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/filter>`_ のソースコードを参照してください。"

#: ../../rst/dev_guide/developing_plugins.rst:336
msgid "Inventory plugins parse inventory sources and form an in-memory representation of the inventory. Inventory plugins were added in Ansible version 2.4."
msgstr "inventory プラグインはインベントリーソースを解析し、インベントリーのインメモリー表示を形成します。inventory プラグインは Ansible バージョン 2.4 で追加されました。"

#: ../../rst/dev_guide/developing_plugins.rst:338
msgid "You can see the details for inventory plugins in the :ref:`developing_inventory` page."
msgstr "inventory プラグインの詳細は、:ref:`developing_inventory` ページを参照してください。"

#: ../../rst/dev_guide/developing_plugins.rst:343
msgid "Lookup plugins"
msgstr "lookup プラグイン"

#: ../../rst/dev_guide/developing_plugins.rst:345
msgid "Lookup plugins pull in data from external data stores. Lookup plugins can be used within playbooks both for looping --- playbook language constructs like ``with_fileglob`` and ``with_items`` are implemented via lookup plugins --- and to return values into a variable or parameter."
msgstr "lookup プラグインは、外部データストアからデータをプルします。lookup プラグインは Playbook 内でループするため (``with_fileglob`` や ``with_items`` などの Playbook 言語の構造は lookup プラグインを介して実装されています)、また変数やパラメーターに値を返すために使用することができます。"

#: ../../rst/dev_guide/developing_plugins.rst:347
msgid "Lookup plugins are expected to return lists, even if just a single element."
msgstr "lookup プラグインは、単一の要素のみであってもリストを返すことが想定されます。"

#: ../../rst/dev_guide/developing_plugins.rst:349
msgid "Ansible includes many :ref:`filters <playbooks_filters>` which can be used to manipulate the data returned by a lookup plugin. Sometimes it makes sense to do the filtering inside the lookup plugin, other times it is better to return results that can be filtered in the playbook. Keep in mind how the data will be referenced when determining the appropriate level of filtering to be done inside the lookup plugin."
msgstr "Ansible には、lookup プラグインが返すデータを操作するために使用できる :ref:`filters <playbooks_filters>` が多数含まれています。lookup プラグイン内でフィルタリングを行うことが理にかなっている場合もあれば、Playbook でフィルタリングできる結果を返す方がよい場合もあります。lookup プラグイン内で実行する適切なフィルタリングレベルを決定するときは、データがどのように参照されるかに留意してください。"

#: ../../rst/dev_guide/developing_plugins.rst:351
msgid "Here's a simple lookup plugin implementation --- this lookup returns the contents of a text file as a variable:"
msgstr "以下は簡単な lookup プラグインの実装です。この lookup は、テキストファイルの内容を変数として返します。"

#: ../../rst/dev_guide/developing_plugins.rst:428
msgid "The following is an example of how this lookup is called:"
msgstr "以下は、このルックアップがどのように呼び出されるかの例になります。"

#: ../../rst/dev_guide/developing_plugins.rst:443
msgid "For example lookup plugins, see the source code for the `lookup plugins included with Ansible Core <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/lookup>`_."
msgstr "lookup プラグインの例は、`Ansible Core に同梱される lookup プラグイン <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/lookup>`_ のソースコードを参照してください。"

#: ../../rst/dev_guide/developing_plugins.rst:445
msgid "For more usage examples of lookup plugins, see :ref:`Using Lookups<playbooks_lookups>`."
msgstr "lookup プラグインのその他の使用例については、「:ref:`検索の使用<playbooks_lookups>`」を参照してください。"

#: ../../rst/dev_guide/developing_plugins.rst:450
msgid "Test plugins"
msgstr "test プラグイン"

#: ../../rst/dev_guide/developing_plugins.rst:452
msgid "Test plugins verify data. They are a feature of Jinja2 and are also available in Jinja2 templates used by the ``template`` module. As with all plugins, they can be easily extended, but instead of having a file for each one you can have several per file. Most of the test plugins shipped with Ansible reside in a ``core.py``. These are specially useful in conjunction with some filter plugins like ``map`` and ``select``; they are also available for conditional directives like ``when:``."
msgstr "テストプラグインはデータを検証します。これは Jinja2 の機能で、``template`` モジュールが使用する Jinja2 テンプレートでも利用できます。他のすべてのプラグインと同様、このプラグインは簡単に拡張できますが、プラグインごとにファイルを作成する代わりに、ファイルごとに複数のプラグインを作成できます。Ansible に同梱されているテストプラグインのほとんどは、``core.py`` に格納されています。これらのプラグインは、``map`` や ``select`` などの filter プラグインと組み合わせて使うと特に便利です。また、``when:`` などの条件付きディレクティブにも利用できます。"

#: ../../rst/dev_guide/developing_plugins.rst:454
msgid "Test plugins do not use the standard configuration and documentation system described above."
msgstr "test プラグインは、上記の標準設定およびドキュメントシステムを使用しません。"

#: ../../rst/dev_guide/developing_plugins.rst:456
msgid "Since Ansible evaluates variables only when they are needed, test plugins should propagate the exceptions ``jinja2.exceptions.UndefinedError`` and ``AnsibleUndefinedVariable`` to ensure undefined variables are only fatal when necessary."
msgstr "Ansibleは必要なときにのみ変数を評価するので、未定義の変数が必要なときにのみ致命的な問題を起こすように、テストプラグインは、例外``jinja2.exceptions.UndefinedError`` と``AnsibleUndefinedVariable`` を伝播させる必要があります。"

#: ../../rst/dev_guide/developing_plugins.rst:467
msgid "For example test plugins, see the source code for the `test plugins included with Ansible Core <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/test>`_."
msgstr "test プラグインの例は、`Ansible Core に同梱される test プラグイン <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/test>`_ のソースコードを参照してください。"

#: ../../rst/dev_guide/developing_plugins.rst:472
msgid "Vars plugins"
msgstr "vars プラグイン"

#: ../../rst/dev_guide/developing_plugins.rst:474
msgid "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."
msgstr "vars プラグインは、インベントリーソース、Playbook、またはコマンドラインに組み込まれていない Ansible の実行に、変数データを追加します。「host_vars」や「group_vars」のような Playbook の構成要素は、vars プラグインを使用します。"

#: ../../rst/dev_guide/developing_plugins.rst:476
msgid "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."
msgstr "vars プラグインは Ansible 2.0 に部分的に実装され、Ansible 2.4 以降では、完全実装になるように書き直されました。vars プラグインはAnsible 2.10以降コレクションのサポート対象となります。"

#: ../../rst/dev_guide/developing_plugins.rst:478
msgid "Older plugins used a ``run`` method as their main body/work:"
msgstr "古いプラグインでは、``run`` メソッドを主要な本文/作業として使用していました。"

#: ../../rst/dev_guide/developing_plugins.rst:486
msgid "Ansible 2.0 did not pass passwords to older plugins, so vaults were unavailable. Most of the work now  happens in the ``get_vars`` method which is called from the VariableManager when needed."
msgstr "Ansible 2.0 は古いプラグインにパスワードを渡さなかったため、vault は利用できませんでした。ほとんどの作業は、必要に応じて VariableManager から呼び出される ``get_vars`` メソッドで実行されるようになりました。"

#: ../../rst/dev_guide/developing_plugins.rst:494
msgid "The parameters are:"
msgstr "パラメーターは以下のとおりです。"

#: ../../rst/dev_guide/developing_plugins.rst:496
msgid "loader: Ansible's DataLoader. The DataLoader can read files, auto-load JSON/YAML and decrypt vaulted data, and cache read files."
msgstr "loader: Ansible の DataLoader。DataLoader は、ファイルの読み取り、JSON/YAML の自動読み込み、vault を使用したデータの復号、および読み取りファイルのキャッシュを行うことができます。"

#: ../../rst/dev_guide/developing_plugins.rst:497
msgid "path: this is 'directory data' for every inventory source and the current play's playbook directory, so they can search for data in reference to them. ``get_vars`` will be called at least once per available path."
msgstr "path: これはすべてのインベントリーソースと現在のプレイの Playbook ディレクトリーの「ディレクトリーデータ」であるため、それを参照するデータを検索することができます。``get_vars`` は、利用可能なパスごとに最低 1 回呼び出されます。"

#: ../../rst/dev_guide/developing_plugins.rst:498
msgid "entities: these are host or group names that are pertinent to the variables needed. The plugin will get called once for hosts and again for groups."
msgstr "entities: 必要な変数に関連付けられるホスト名またはグループ名です。プラグインはホストに対して 1 回呼び出され、グループに対して再度呼び出されます。"

#: ../../rst/dev_guide/developing_plugins.rst:500
msgid "This ``get_vars`` method just needs to return a dictionary structure with the variables."
msgstr "この ``get_vars`` メソッドは変数を含むディクショナリー構造を返す必要があります。"

#: ../../rst/dev_guide/developing_plugins.rst:502
msgid "Since Ansible version 2.4, vars plugins only execute as needed when preparing to execute a task. This avoids the costly 'always execute' behavior that occurred during inventory construction in older versions of Ansible. Since Ansible version 2.10, vars plugin execution can be toggled by the user to run when preparing to execute a task or after importing an inventory source."
msgstr "Ansible バージョン 2.4 以降、タスク実行の準備時に必要に応じて vars プラグインのみを実行します。これにより、古いバージョンの Ansible のインベントリー構築中に発生した、費用のかかる「常に実行」動作が回避されます。Ansible バージョン 2.10 以降、vars プラグインの実行は、タスクの実行準備時またはインベントリーソースのインポート後に実行するようにユーザーが切り替えることができます。"

#: ../../rst/dev_guide/developing_plugins.rst:504
msgid "The user must explicitly enable vars plugins that reside in a collection. See :ref:`enable_vars` for details."
msgstr "ユーザーは、コレクションにある vars プラグインを明示的に有効にする必要があります。詳細は、:ref:`enable_vars` を参照してください。"

#: ../../rst/dev_guide/developing_plugins.rst:506
msgid "Legacy vars plugins are always loaded and run by default. You can prevent them from automatically running by setting ``REQUIRES_ENABLED`` to True."
msgstr "レガシー vars プラグインは常に読み込まれ、実行されます。``REQUIRES_ENABLED`` を True に設定すると、自動的に実行しないようにできます。"

#: ../../rst/dev_guide/developing_plugins.rst:513
msgid "Include the ``vars_plugin_staging`` documentation fragment to allow users to determine when vars plugins run."
msgstr "``vars_plugin_staging`` ドキュメントフラグメントを追加して、ユーザーが when vars プラグインの実行を判別できるようにします。"

#: ../../rst/dev_guide/developing_plugins.rst:533
msgid "For example vars plugins, see the source code for the `vars plugins included with Ansible Core <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/vars>`_."
msgstr "vars プラグインの例は、`Ansible Core に含まれる vars プラグイン <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/vars>`_ のソースコードを参照してください。"

#: ../../rst/dev_guide/developing_plugins.rst:543
msgid "Learn about how to develop dynamic inventory sources"
msgstr "動的インベントリーソースの開発方法について"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:6
msgid "Ansible module architecture"
msgstr "Ansible モジュールのアーキテクチャー"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:8
msgid "If you are working on the ``ansible-core`` code, writing an Ansible module, or developing an action plugin, you may need to understand how Ansible's program flow executes. If you are just using Ansible Modules in playbooks, you can skip this section."
msgstr "``ansible-core`` コードを使用している場合、Ansible モジュールの作成、またはアクションプラグインの開発では、Ansible のプログラムフローがどのように実行されるかを理解しないといけない場合があります。Playbook で Ansible モジュールを使用しているだけの場合は、このセクションをスキップできます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:16
msgid "Types of modules"
msgstr "モジュールの種類"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:18
msgid "Ansible supports several different types of modules in its code base. Some of these are for backwards compatibility and others are to enable flexibility."
msgstr "Ansible は、コードベースでいくつかの異なるタイプのモジュールをサポートしています。下位互換性のためのものもあり、柔軟性を可能にするものもあります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:26
msgid "Action plugins look like modules to anyone writing a playbook. Usage documentation for most action plugins lives inside a module of the same name. Some action plugins do all the work, with the module providing only documentation. Some action plugins execute modules. The ``normal`` action plugin executes modules that don't have special action plugins. Action plugins always execute on the controller."
msgstr "action プラグインは、Playbook を作成する人にとってはモジュールのように見えます。ほとんどの action プラグインの使用方法に関するドキュメントは、同じ名前のモジュール内にあります。action プラグインの中には、すべての作業を行なうものもありますが、このモジュールはドキュメントのみを提供します。一部の action プラグインはモジュールを実行します。action プラグイン ``normal`` は、特別な action プラグインを持たないモジュールを実行します。action プラグインは常にコントローラーで実行します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:28
msgid "Some action plugins do all their work on the controller. For example, the :ref:`debug <debug_module>` action plugin (which prints text for the user to see) and the :ref:`assert <assert_module>` action plugin (which tests whether values in a playbook satisfy certain criteria) execute entirely on the controller."
msgstr "action プラグインによってコントローラーですべての作業が機能します。たとえば、action プラグイン :ref:`debug <debug_module>` (ユーザーに表示できるようにテキストを出力する) および action プラグイン :ref:`assert <assert_module>` (Playbook の値が特定の基準を満たすかどうかのテスト) など、コントローラー上で完全に実行します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:33
msgid "Most action plugins set up some values on the controller, then invoke an actual module on the managed node that does something with these values. For example, the :ref:`template <template_module>` action plugin takes values from the user to construct a file in a temporary location on the controller using variables from the playbook environment. It then transfers the temporary file to a temporary file on the remote system. After that, it invokes the :ref:`copy module <copy_module>` which operates on the remote system to move the file into its final location, sets file permissions, and so on."
msgstr "ほとんどのアクションプラグインは、コントローラーにいくつかの値を設定した後、管理ノードで実際のモジュールを呼び出して、これらの値を使用して何かを行います。たとえば、action プラグイン :ref:`template <template_module>` は、ユーザーから値を受け取り、Playbook 環境からの変数を使用して、コントローラーの一時的な場所にファイルを作成します。その後、その一時ファイルを、リモートシステムの一時ファイルに転送します。その後、リモートシステム上で動作する :ref:`copy モジュール <copy_module>` を起動して、ファイルを最終的な場所に移動させ、ファイルのパーミッションを設定するなどの作業を行います。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:44
msgid "New-style modules"
msgstr "新スタイルのモジュール"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:46
msgid "All of the modules that ship with Ansible fall into this category. While you can write modules in any language, all official modules (shipped with Ansible) use either Python or PowerShell."
msgstr "Ansible に同梱されるモジュールはすべてこのカテゴリーに分類されます。モジュールは任意の言語で記述できますが、(Ansible に同梱されている) 正式なモジュールはすべて Python または PowerShell を使用します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:48
msgid "New-style modules have the arguments to the module embedded inside of them in some manner. Old-style modules must copy a separate file over to the managed node, which is less efficient as it requires two over-the-wire connections instead of only one."
msgstr "新しいスタイルのモジュールには、なんらかの方法で実装されているモジュールに引数があります。古いスタイルのモジュールは、管理ノードに個別のファイルを管理ノードにコピーする必要があります。これは、1 つの接続ではなく、ネットワーク上の接続が 2 つ必要であるため、効率が悪くなります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:56
msgid "Python"
msgstr "Python"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:58
msgid "New-style Python modules use the :ref:`Ansiballz` framework for constructing modules. These modules use imports from :code:`ansible.module_utils` to pull in boilerplate module code, such as argument parsing, formatting of return values as :term:`JSON`, and various file operations."
msgstr "新しいスタイルの Python モジュールは、モジュールの構築に :ref:`Ansiballz` フレームワークを使用します。これらのモジュールは、:code:`ansible.module_utils` からインポートを使用し、引数の解析、:term:`JSON` などのさまざまなファイル操作の戻り値のフォーマットなど、boilerplate モジュールコードとして取得します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:63
msgid "In Ansible, up to version 2.0.x, the official Python modules used the :ref:`module_replacer` framework.  For module authors, :ref:`Ansiballz` is largely a superset of :ref:`module_replacer` functionality, so you usually do not need to understand the differences between them."
msgstr "バージョン 2.0.x までの Ansible では、公式の Python モジュールが :ref:`module_replacer`を使用していました。:ref:`Ansiballz` は、:ref:`module_replacer` 機能の上位セットであるため、通常はモジュール作成者がこれらの違いを理解する必要はありません。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:71
msgid "PowerShell"
msgstr "PowerShell"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:73
msgid "New-style PowerShell modules use the :ref:`module_replacer` framework for constructing modules. These modules get a library of PowerShell code embedded in them before being sent to the managed node."
msgstr "新しいスタイルの PowerShell モジュールは、モジュールの構築に :ref:`module_replacer` を使用します。これらのモジュールは、管理ノードに送信される前にそれらに組み込まれている PowerShell コードのライブラリーを取得します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:80
msgid "JSONARGS modules"
msgstr "JSONARGS モジュール"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:82
msgid "These modules are scripts that include the string ``<<INCLUDE_ANSIBLE_MODULE_JSON_ARGS>>`` in their body. This string is replaced with the JSON-formatted argument string. These modules typically set a variable to that value like this:"
msgstr "これらのモジュールは、本文に文字列 ``<<INCLUDE_ANSIBLE_MODULE_JSON_ARGS>>`` が含まれるスクリプトです。この文字列は JSON 形式の引数文字列に置き換えられます。これらのモジュールは、通常、変数を以下のような値に設定します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:90
msgid "Which is expanded as:"
msgstr "これは以下のように展開されます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:96
msgid "Ansible outputs a :term:`JSON` string with bare quotes. Double quotes are used to quote string values, double quotes inside of string values are backslash escaped, and single quotes may appear unescaped inside of a string value. To use JSONARGS, your scripting language must have a way to handle this type of string. The example uses Python's triple quoted strings to do this. Other scripting languages may have a similar quote character that won't be confused by any quotes in the JSON or it may allow you to define your own start-of-quote and end-of-quote characters. If the language doesn't give you any of these then you'll need to write a :ref:`non-native JSON module <flow_want_json_modules>` or :ref:`Old-style module <flow_old_style_modules>` instead."
msgstr "Ansible は、:term:`JSON` の文字列を引用符なしで出力します。文字列値の引用には二重引用符が使用され、文字列値の中の二重引用符はバックスラッシュでエスケープされ、文字列値の中の一重引用符はエスケープされずに表示されることがあります。JSONARGS を使用するには、スクリプト言語がこの種の文字列を処理する方法を備えている必要があります。この例では、Python の三重引用符文字列を使用しています。他のスクリプト言語では、JSON 内の引用符と混同されないような同様の引用符文字が用意されていたり、独自の引用開始文字や引用終了文字を定義できたりする場合があります。お使いの言語がこれを提供していない場合は、代わりに :ref:`非ネイティブ JSON モジュール <flow_want_json_modules>` または :ref:`古いスタイルのモジュール <flow_old_style_modules>` を記述する必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:108
msgid "These modules typically parse the contents of ``json_arguments`` using a JSON library and then use them as native variables throughout the code."
msgstr "これらのモジュールは通常、JSON ライブラリーを使用して ``json_arguments`` のコンテンツを解析し、次にコード全体でネイティブ変数として使用します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:114
msgid "Non-native want JSON modules"
msgstr "ネイティブ以外の JSON モジュール"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:116
msgid "If a module has the string ``WANT_JSON`` in it anywhere, Ansible treats it as a non-native module that accepts a filename as its only command line parameter. The filename is for a temporary file containing a :term:`JSON` string containing the module's parameters. The module needs to open the file, read and parse the parameters, operate on the data, and print its return data as a JSON encoded dictionary to stdout before exiting."
msgstr "モジュールに文字列 ``WANT_JSON`` があると、Ansible は、ファイル名をコマンドラインパラメーターとしてのみ許可する非ネイティブモジュールとして扱います。ファイル名は、モジュールのパラメーターを含む :term:`JSON` 文字列を含む一時的なファイル向けです。モジュールはファイルを開き、パラメーターを読み取りおよび解析し、データで操作し、終了する前にその戻り値を JSON エンコードディレクトリーとして stdout に出力する必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:123
msgid "These types of modules are self-contained entities. As of Ansible 2.1, Ansible only modifies them to change a shebang line if present."
msgstr "これらのモジュールタイプは自己完結型エンティティーです。Ansible 2.1 以降、Ansible では、存在する場合にのみ、シバン行を変更するようにそれらを変更します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:126
msgid "Examples of Non-native modules written in ruby are in the `Ansible for Rubyists <https://github.com/ansible/ansible-for-rubyists>`_ repository."
msgstr "Ruby で書かれた非ネイティブモジュールの例は、`Ansible for Rubyists <https://github.com/ansible/ansible-for-rubyists>`_ リポジトリーにあります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:132
msgid "Binary modules"
msgstr "バイナリーモジュール"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:134
msgid "From Ansible 2.2 onwards, modules may also be small binary programs. Ansible doesn't perform any magic to make these portable to different systems so they may be specific to the system on which they were compiled or require other binary runtime dependencies. Despite these drawbacks, you may have to compile a custom module against a specific binary library if that's the only way to get access to certain resources."
msgstr "Ansible 2.2 以降、モジュールは小規模のバイナリープログラムでもあります。Ansible は、これらを異なるシステムに移植できるようにする機能がないため、コンパイルされたシステムに固有のものであったり、他のバイナリーランタイムに依存したものが必要であったりします。このような欠点はありますが、特定のリソースにアクセスするための唯一の方法であれば、特定のバイナリーライブラリーに対するカスタムモジュールのコンパイルが必要になる場合があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:141
msgid "Binary modules take their arguments and return data to Ansible in the same way as :ref:`want JSON modules <flow_want_json_modules>`."
msgstr "バイナリモジュールは、引数を取り、:ref:`want JSON モジュール <flow_want_json_modules>` と同じ方法でデータを Ansible に返します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:144
msgid "One example of a `binary module <https://github.com/ansible/ansible/blob/devel/test/integration/targets/binary_modules/library/helloworld.go>`_ written in go."
msgstr "Go で記述された ` バイナリーモジュール <https://github.com/ansible/ansible/blob/devel/test/integration/targets/binary_modules/library/helloworld.go>`_ の一例"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:151
msgid "Old-style modules"
msgstr "古いスタイルのモジュール"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:153
msgid "Old-style modules are similar to :ref:`want JSON modules <flow_want_json_modules>`, except that the file that they take contains ``key=value`` pairs for their parameters instead of :term:`JSON`. Ansible decides that a module is old-style when it doesn't have any of the markers that would show that it is one of the other types."
msgstr "古いスタイルのモジュールは、:ref:`want JSON モジュール <flow_want_json_modules>` と似ていますが、使用するファイルが :term:`JSON` ではなく ``key=value`` のペアをパラメータに含んでいる点が異なります。Ansible は、モジュールに他のタイプの 1 つであることを示すマーカーがないと、そのモジュールが古いスタイルであると判断します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:162
msgid "How modules are executed"
msgstr "モジュールの実行方法"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:164
msgid "When a user uses :program:`ansible` or :program:`ansible-playbook`, they specify a task to execute. The task is usually the name of a module along with several parameters to be passed to the module. Ansible takes these values and processes them in various ways before they are finally executed on the remote machine."
msgstr ":program:`ansible` または :program:`ansible-playbook` を使用する場合は、実行するタスクを指定します。タスクは通常、モジュールに渡す複数のパラメーターを持つモジュールの名前です。Ansible はこれらの値を取得し、さまざまな方法で処理してから、最終的にリモートマシンで実行されます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:173
msgid "Executor/task_executor"
msgstr "Executor/task_executor"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:175
msgid "The TaskExecutor receives the module name and parameters that were parsed from the :term:`playbook <playbooks>` (or from the command line in the case of :command:`/usr/bin/ansible`). It uses the name to decide whether it's looking at a module or an :ref:`Action Plugin <flow_action_plugins>`. If it's a module, it loads the :ref:`Normal Action Plugin <flow_normal_action_plugin>` and passes the name, variables, and other information about the task and play to that Action Plugin for further processing."
msgstr "TaskExecutor は、:term:`Playbook <playbooks>` (:command:`/usr/bin/ansible` の場合はコマンドライン) から解析されたモジュール名とパラメーターを受け取ります。これは、モジュールを見て、または :ref:`action プラグイン <flow_action_plugins>` を見ているかを判断するために名前を使用します。モジュールの場合は、:ref:`Normal action プラグイン <flow_normal_action_plugin>` を読み込み、タスクとプレイに関する名前、変数、およびその他の情報をそのアクションプラグインに渡して、さらに処理します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:186
msgid "The ``normal`` action plugin"
msgstr "action プラグイン ``normal``"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:188
msgid "The ``normal`` action plugin executes the module on the remote host. It is the primary coordinator of much of the work to actually execute the module on the managed machine."
msgstr "action プラグイン ``normal`` は、リモートホストでモジュールを実行します。管理マシンでモジュールを実際に実行する多くの作業に対する主要な調整役です。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:192
msgid "It loads the appropriate connection plugin for the task, which then transfers or executes as needed to create a connection to that host."
msgstr "タスクに適切な connection プラグインを読み込み、そのホストへの接続を作成するために必要に応じて転送や実行を行います。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:194
msgid "It adds any internal Ansible properties to the module's parameters (for instance, the ones that pass along ``no_log`` to the module)."
msgstr "モジュールのパラメーターに、Ansible の内部プロパティーを追加します (たとえば ``no_log`` をモジュールに渡すものなど)。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:196
msgid "It works with other plugins (connection, shell, become, other action plugins) to create any temporary files on the remote machine and cleans up afterwards."
msgstr "これは、他のプラグイン (connection、shell、become、その他の action プラグイン) と連携して、リモートマシンに一時ファイルを作成し、後で削除します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:199
msgid "It pushes the module and module parameters to the remote host, although the :ref:`module_common <flow_executor_module_common>` code described in the next section decides which format those will take."
msgstr "これに、モジュールおよびモジュールパラメーターがリモートホストにプッシュされますが、次のセクションで説明する :ref:`module_common <flow_executor_module_common>` コードが、どの形式を取るのか決定します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:203
msgid "It handles any special cases regarding modules (for instance, async execution, or complications around Windows modules that must have the same names as Python modules, so that internal calling of modules from other Action Plugins work.)"
msgstr "モジュールに関する特殊なケースを処理します (たとえば、非同期実行や、Python モジュールと同じ名前を持たなければならない Windows モジュールの複雑さなど。これにより、他の action プラグインからのモジュールの内部呼び出しが機能します)。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:206
msgid "Much of this functionality comes from the `BaseAction` class, which lives in :file:`plugins/action/__init__.py`. It uses the ``Connection`` and ``Shell`` objects to do its work."
msgstr "この機能の多くは、`BaseAction` クラス (:file:`plugins/action/__init__.py` にある) から取得されます。これは、``Connection`` オブジェクトおよび ``Shell`` オブジェクトを使用して作業を行います。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:211
msgid "When :term:`tasks <tasks>` are run with the ``async:`` parameter, Ansible uses the ``async`` Action Plugin instead of the ``normal`` Action Plugin to invoke it. That program flow is currently not documented. Read the source for information on how that works."
msgstr ":term:`タスク <tasks>` を ``async:`` パラメーターで実行している場合、Ansible は、action プラグイン ``normal`` の代わりに ``async`` を使用してそれを呼び出します。そのプログラムフローは現在文書化されていません。それがどのように機能するかについては、ソースをお読みください。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:219
msgid "Executor/module_common.py"
msgstr "Executor/module_common.py"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:221
msgid "Code in :file:`executor/module_common.py` assembles the module to be shipped to the managed node. The module is first read in, then examined to determine its type:"
msgstr ":file:`executor/module_common.py` のコードは、管理ノードに同梱するモジュールをアセンブルします。まず、モジュールが最初に読み込まれ、その後はそのタイプを判断します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:225
msgid ":ref:`PowerShell <flow_powershell_modules>` and :ref:`JSON-args modules <flow_jsonargs_modules>` are passed through :ref:`Module Replacer <module_replacer>`."
msgstr ":ref:`PowerShell <flow_powershell_modules>` および :ref:`JSON-args モジュール <flow_jsonargs_modules>` は、:ref:`Module Replacer <module_replacer>` 経由で渡されます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:226
msgid "New-style :ref:`Python modules <flow_python_modules>` are assembled by :ref:`Ansiballz`."
msgstr "新しいスタイルの :ref:`Python モジュール <flow_python_modules>` は :ref:`Ansiballz` によりアセンブルされます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:227
msgid ":ref:`Non-native-want-JSON <flow_want_json_modules>`, :ref:`Binary modules <flow_binary_modules>`, and :ref:`Old-Style modules <flow_old_style_modules>` aren't touched by either of these and pass through unchanged."
msgstr ":ref:`Non-native-want-JSON <flow_want_json_modules>`、:ref:`バイナリーモジュール <flow_binary_modules>`、および :ref:`古いスタイルのモジュール <flow_old_style_modules>` は、これらのどちらにも触れられず、変更されずにそのまま通過します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:229
msgid "After the assembling step, one final modification is made to all modules that have a shebang line. Ansible checks whether the interpreter in the shebang line has a specific path configured via an ``ansible_$X_interpreter`` inventory variable. If it does, Ansible substitutes that path for the interpreter path given in the module. After this, Ansible returns the complete module data and the module type to the :ref:`Normal Action <flow_normal_action_plugin>` which continues execution of the module."
msgstr "アセンブル手順後、シバン行を持つすべてのモジュールに最終変更が行われます。Ansible は、シバン行内のインタープリターに ``ansible_$X_interpreter`` インベントリー変数を介して特定のパスが設定されているかどうかを確認します。パスがある場合、Ansible は、そのパスを、そのモジュールに指定されているインタープリターパスに置き換えます。その後、Ansible は完全なモジュールデータを返し、モジュールタイプを :ref:`normal action <flow_normal_action_plugin>` に返し、モジュールの実行を続行します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:239
msgid "Assembler frameworks"
msgstr "アセンブラーフレームワーク"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:241
msgid "Ansible supports two assembler frameworks: Ansiballz and the older Module Replacer."
msgstr "Ansible は、2 つのアセンブラフレームワーク (Ansiballz と古い Module Replacer) をサポートしています。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:246
msgid "Module Replacer framework"
msgstr "Module Replacer フレームワーク"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:248
msgid "The Module Replacer framework is the original framework implementing new-style modules, and is still used for PowerShell modules. It is essentially a preprocessor (like the C Preprocessor for those familiar with that programming language). It does straight substitutions of specific substring patterns in the module file. There are two types of substitutions:"
msgstr "モジュール置換フレームワークは、新しいスタイルモジュールを実装し、引き続き PowerShell モジュール向けに使用されています。基本的には、(そのプログラミング言語に精通している C プロセッサーなど) です。モジュールファイル内の特定の従属文字列パターンを直接置換します。置換には 2 つのタイプがあります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:254
msgid "Replacements that only happen in the module file. These are public replacement strings that modules can utilize to get helpful boilerplate or access to arguments."
msgstr "モジュールファイルでのみ実行する置換。モジュールは、便利な boilerplate や引数へのアクセスに使用できるパブリックの置換文字列です。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:258
msgid ":code:`from ansible.module_utils.MOD_LIB_NAME import *` is replaced with the contents of the :file:`ansible/module_utils/MOD_LIB_NAME.py`  These should only be used with :ref:`new-style Python modules <flow_python_modules>`."
msgstr ":code:`from ansible.module_utils.MOD_LIB_NAME import *` は、:file:`ansible/module_utils/MOD_LIB_NAME.py` の内容に置き換えます。これらは、:ref:`新しいスタイルの Python モジュール <flow_python_modules>` と併用する必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:261
msgid ":code:`#<<INCLUDE_ANSIBLE_MODULE_COMMON>>` is equivalent to :code:`from ansible.module_utils.basic import *` and should also only apply to new-style Python modules."
msgstr ":code:`#<<INCLUDE_ANSIBLE_MODULE_COMMON>>` は、:code:`from ansible.module_utils.basic import *` と同等で、新しいスタイルの Python モジュールのみに適用する必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:264
msgid ":code:`# POWERSHELL_COMMON` substitutes the contents of :file:`ansible/module_utils/powershell.ps1`. It should only be used with :ref:`new-style Powershell modules <flow_powershell_modules>`."
msgstr ":code:`# POWERSHELL_COMMON` は、:file:`ansible/module_utils/powershell.ps1` の内容を置き換えます。これは、:ref:`新しいスタイルの Powershell モジュール <flow_powershell_modules>` と併用する必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:268
msgid "Replacements that are used by ``ansible.module_utils`` code. These are internal replacement patterns. They may be used internally, in the above public replacements, but shouldn't be used directly by modules."
msgstr "``ansible.module_utils`` コードにより使用される代替品。これらは内部交換パターンです。これらは、上記のパブリック置換で内部的に使用できますが、モジュールで直接使用しないでください。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:270
msgid ":code:`\"<<ANSIBLE_VERSION>>\"` is substituted with the Ansible version.  In :ref:`new-style Python modules <flow_python_modules>` under the :ref:`Ansiballz` framework the proper way is to instead instantiate an `AnsibleModule` and then access the version from :attr:``AnsibleModule.ansible_version``."
msgstr ":code:`\"<<ANSIBLE_VERSION>>\"` は、Ansible バージョンに置き換えられます。:ref:`Ansiballz` フレームワークの下の :ref:`新しいスタイルの Python モジュール <flow_python_modules>` で適切な方法は、代わりに `AnsibleModule` をインスタンス化し、:attr:``AnsibleModule.ansible_version`` からバージョンにアクセスすることです。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:275
msgid ":code:`\"<<INCLUDE_ANSIBLE_MODULE_COMPLEX_ARGS>>\"` is substituted with a string which is the Python ``repr`` of the :term:`JSON` encoded module parameters. Using ``repr`` on the JSON string makes it safe to embed in a Python file. In new-style Python modules under the Ansiballz framework this is better accessed by instantiating an `AnsibleModule` and then using :attr:`AnsibleModule.params`."
msgstr ":code:`\"<<INCLUDE_ANSIBLE_MODULE_COMPLEX_ARGS>>\"` は、:term:`JSON` でエンコードされたモジュールパラメーターの Python ``repr`` の文字列に置き換えます。JSON 文字列で ``repr`` を使用すると、Python ファイルに安全に埋め込むことができます。Ansiballz フレームワークの新しいスタイル Python モジュールでは、`AnsibleModule` をインスタンス化してから :attr:`AnsibleModule.params` を使用することで、これはより適切にアクセスされます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:281
msgid ":code:`<<SELINUX_SPECIAL_FILESYSTEMS>>` substitutes a string which is a comma separated list of file systems which have a file system dependent security context in SELinux. In new-style Python modules, if you really need this you should instantiate an `AnsibleModule` and then use :attr:`AnsibleModule._selinux_special_fs`. The variable has also changed from a comma separated string of file system names to an actual python list of filesystem names."
msgstr ":code:`<<SELINUX_SPECIAL_FILESYSTEMS>>` は、SELinux にファイルシステムに依存するセキュリティーコンテキストがあるファイルシステムのコンマ区切りの一覧である文字列を置き換えます。新しいスタイルの Python モジュールで `AnsibleModule` をインスタンス化してから、:attr:`AnsibleModule._selinux_special_fs` を使用してください。また、この変数は、ファイルシステム名のコンマ区切りの文字列から、ファイルシステム名の実際の python のリストに変更されています。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:288
msgid ":code:`<<INCLUDE_ANSIBLE_MODULE_JSON_ARGS>>` substitutes the module parameters as a JSON string. Care must be taken to properly quote the string as JSON data may contain quotes. This pattern is not substituted in new-style Python modules as they can get the module parameters another way."
msgstr ":code:`<<INCLUDE_ANSIBLE_MODULE_JSON_ARGS>>` はモジュールパラメーターを JSON 文字列として置き換えます。JSON データには引用符が含まれている可能性があるため、文字列を適切に引用符で囲むように注意する必要があります。このパターンは、モジュールパラネーターを別の方法で取得できるため、新しいスタイルの Python モジュールでは置き換えられません。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:293
msgid "The string :code:`syslog.LOG_USER` is replaced wherever it occurs with the ``syslog_facility`` which was named in :file:`ansible.cfg` or any ``ansible_syslog_facility`` inventory variable that applies to this host.  In new-style Python modules this has changed slightly. If you really need to access it, you should instantiate an `AnsibleModule` and then use :attr:`AnsibleModule._syslog_facility` to access it. It is no longer the actual syslog facility and is now the name of the syslog facility. See the :ref:`documentation on internal arguments <flow_internal_arguments>` for details."
msgstr "文字列 :code:`syslog.LOG_USER` は、:file:`ansible.cfg` またはこのホストに適用される ``ansible_syslog_facility`` インベントリー変数で囲まれている ``syslog_facility`` に置き換えられます。新しいスタイルの Python モジュールでは、これは若干変更になりました。本当にアクセスする必要がある場合は、`AnsibleModule` をインスタンス化し、その後 :attr:`AnsibleModule._syslog_facility` を使用してアクセスする必要があります。これは実際の syslog 機能ではなく、syslog 機能の名前になります。詳細は、「:ref:`内部引数のドキュメント <flow_internal_arguments>`」を参照してください。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:306
msgid "Ansiballz framework"
msgstr "Ansiballz フレームワーク"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:308
msgid "The Ansiballz framework was adopted in Ansible 2.1 and is used for all new-style Python modules. Unlike the Module Replacer, Ansiballz uses real Python imports of things in :file:`ansible/module_utils` instead of merely preprocessing the module. It does this by constructing a zipfile -- which includes the module file, files in :file:`ansible/module_utils` that are imported by the module, and some boilerplate to pass in the module's parameters. The zipfile is then Base64 encoded and wrapped in a small Python script which decodes the Base64 encoding and places the zipfile into a temp directory on the managed node. It then extracts just the Ansible module script from the zip file and places that in the temporary directory as well. Then it sets the PYTHONPATH to find Python modules inside of the zip file and imports the Ansible module as the special name, ``__main__``. Importing it as ``__main__`` causes Python to think that it is executing a script rather than simply importing a module. This lets Ansible run both the wrapper script and the module code in a single copy of Python on the remote machine."
msgstr "Ansiblez フレームワークは Ansible 2.1 で採用され、すべての新しいスタイルの Python モジュールに使用されます。Module Replacer とは異なり、Ansiballz は、単にモジュールを前処理するだけではなく、:file:`ansible/module_utils` に含まれるものを実際に Python でインポートします。これを行うには、zipfile を構築します。これには、モジュールファイル、モジュールがインポートする :file:`ansible/module_utils` のファイル、およびモジュールのパラメーターを渡す boilerplate が含まれます。その後、zipfile は Base64 でエンコードされ、小さな Python スクリプトでラップされます。このスクリプトは Base64 エンコードをデコードし、zipfile を管理対象ノードの一時ディレクトリーに配置します。その後、zip ファイルから Ansible モジュールスクリプトのみを抽出し、一時ディレクトリーに配置します。その後、PYTHONPATH を設定して、zip ファイルから Python モジュールを検索し、Ansible モジュールを特殊な名前 ``__main__`` としてインポートします。``__main__`` としてインポートすると、Python は単にモジュールをインポートするのではなく、スクリプトを実行していると見なすようになります。これにより、Ansible は、ラッパースクリプトとモジュールコードの両方を、リモートマシンの Python の単一コピーで実行できます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:322
msgid "Ansible wraps the zipfile in the Python script for two reasons:"
msgstr "Ansible が Python スクリプトで zip ファイルをラップするには、以下の 2 つの理由があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:324
msgid "for compatibility with Python 2.6 which has a less functional version of Python's ``-m`` command line switch."
msgstr "Python の ``-m`` コマンドラインスイッチの機能が少ない Python 2.6 との互換性のため。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:327
msgid "so that pipelining will function properly. Pipelining needs to pipe the Python module into the Python interpreter on the remote node. Python understands scripts on stdin but does not understand zip files."
msgstr "パイプ処理が適切に機能します。Pipelining は Python モジュールをリモートノード上の Python インタープリターにパイプする必要があります。Python は stdin のスクリプトを理解しますが、zip ファイルを理解しません。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:331
msgid "Prior to Ansible 2.7, the module was executed via a second Python interpreter instead of being executed inside of the same process. This change was made once Python-2.4 support was dropped to speed up module execution."
msgstr "Ansible 2.7 より前のバージョンでは、同じプロセス内で実行されるのではなく 2 つ目の Python インタープリター経由で実行されます。この変更は、Python-2.4 サポートが破棄され、モジュール実行のスピードを高めました。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:335
msgid "In Ansiballz, any imports of Python modules from the :py:mod:`ansible.module_utils` package trigger inclusion of that Python file into the zipfile. Instances of :code:`#<<INCLUDE_ANSIBLE_MODULE_COMMON>>` in the module are turned into :code:`from ansible.module_utils.basic import *` and :file:`ansible/module-utils/basic.py` is then included in the zipfile. Files that are included from :file:`module_utils` are themselves scanned for imports of other Python modules from :file:`module_utils` to be included in the zipfile as well."
msgstr "Ansiballzでは、:py:mod:`ansible.module_utils` パッケージからの Python モジュールのインポートにより、その Python ファイルが zip ファイルに追加されます。モジュール内の :code:`#<<INCLUDE_ANSIBLE_MODULE_COMMON>>` のインスタンスは :code:`from ansible.module_utils.basic import *` に変換され、その後 :file:`ansible/module-utils/basic.py` が zip ファイルに追加されます。:file:`module_utils` から追加されるファイルは、それ自体が :file:`module_utils` からの他の Python モジュールのインポートをスキャンし、同じように zip ファイルに追加します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:345
msgid "At present, the Ansiballz Framework cannot determine whether an import should be included if it is a relative import. Always use an absolute import that has :py:mod:`ansible.module_utils` in it to allow Ansiballz to determine that the file should be included."
msgstr "現状、Aweraiballz Framework は、相対インポートの場合にインポートを含める必要があるかどうかを判別できません。常に、その中に :py:mod:`ansible.module_utils` がある絶対インポートを使用して、このファイルを同梱する必要があると判断することができます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:354
msgid "Passing args"
msgstr "引数を渡す"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:356
msgid "Arguments are passed differently by the two frameworks:"
msgstr "以下の 2 つのフレームワークでは、引数の渡し方が異なります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:358
msgid "In :ref:`module_replacer`, module arguments are turned into a JSON-ified string and substituted into the combined module file."
msgstr ":ref:`module_replacer` では、モジュールの引数は JSON 化された文字列に変換され、結合されたモジュールファイルに置き換えられます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:359
msgid "In :ref:`Ansiballz`, the JSON-ified string is part of the script which wraps the zipfile. Just before the wrapper script imports the Ansible module as ``__main__``, it monkey-patches the private, ``_ANSIBLE_ARGS`` variable in ``basic.py`` with the variable values. When a :class:`ansible.module_utils.basic.AnsibleModule` is instantiated, it parses this string and places the args into :attr:`AnsibleModule.params` where it can be accessed by the module's other code."
msgstr ":ref:`Ansiballz` では、JSON 化された文字列は、zip ファイルをラップするスクリプトの一部です。ラッパースクリプトが Ansible モジュールを ``__main__`` としてインポートする直前に、``basic.py`` のプライベート変数 ``_ANSIBLE_ARGS`` を変数値でモンキーパッチしています。:class:`ansible.module_utils.basic.AnsibleModule` がインスタンス化されると、この文字列を解析し、引数を :attr:`AnsibleModule.params` に配置し、モジュールの他のコードがアクセスできる場所に置きます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:362
msgid "If you are writing modules, remember that the way we pass arguments is an internal implementation detail: it has changed in the past and will change again as soon as changes to the common module_utils code allow Ansible modules to forgo using :class:`ansible.module_utils.basic.AnsibleModule`. Do not rely on the internal global ``_ANSIBLE_ARGS`` variable."
msgstr "モジュールを作成している場合は、引数を渡す方法は内部実装の詳細であることに注意してください。これは過去に変更されており、共通のモジュールユーティリティーコードを変更すると、Ansible モジュールが :class:`ansible.module_utils.basic.AnsibleModule` の使用をやめるとすぐに再び変更されます。内部グローバル変数 ``_ANSIBLE_ARGS`` に依存しないでください。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:365
msgid "Very dynamic custom modules which need to parse arguments before they instantiate an ``AnsibleModule`` may use ``_load_params`` to retrieve those parameters. Although ``_load_params`` may change in breaking ways if necessary to support changes in the code, it is likely to be more stable than either the way we pass parameters or the internal global variable."
msgstr "``AnsibleModule`` をインスタンス化する前に引数を解析する必要のある非常に動的なカスタムモジュールは、``_load_params`` を使用してこれらのパラメーターを取得する場合があります。コードの変更をサポートする必要がある場合は、``_load_params`` が破壊的な方法で変更する可能性がありますが、パラメーターまたは内部グローバル変数を渡す方法よりも安定している可能性があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:371
msgid "Prior to Ansible 2.7, the Ansible module was invoked in a second Python interpreter and the arguments were then passed to the script over the script's stdin."
msgstr "Ansible 2.7 より前のバージョンでは、Ansible モジュールは 2 番目の Python インタープリターで呼び出され、引数はスクリプトの標準入力 (stdin) を介してスクリプトに渡されていました。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:378
msgid "Internal arguments"
msgstr "内部引数"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:380
msgid "Both :ref:`module_replacer` and :ref:`Ansiballz` send additional arguments to the module beyond those which the user specified in the playbook. These additional arguments are internal parameters that help implement global Ansible features. Modules often do not need to know about these explicitly as the features are implemented in :py:mod:`ansible.module_utils.basic` but certain features need support from the module so it's good to know about them."
msgstr ":ref:`module_replacer` および :ref:`Ansiballz` の両方は、Playbook で指定したユーザー以外に追加の引数をモジュールに送信します。これらの追加の引数は、Ansible のグローバル機能の実装に役立つ内部パラメーターです。これらの機能は、:py:mod:`ansible.module_utils.basic` に実装されているため、モジュールが明示的に理解する必要がないことがしばしばありますが、機能についてある程度理解できるように、モジュールから特定の機能のサポートが必要になります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:387
msgid "The internal arguments listed here are global. If you need to add a local internal argument to a custom module, create an action plugin for that specific module - see ``_original_basename`` in the `copy action plugin <https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/action/copy.py#L329>`_ for an example."
msgstr "ここに記載されている内部引数はグローバルです。カスタムモジュールにローカルの内部引数を追加する必要がある場合は、その特定のモジュールに action プラグインを作成してください。例は、「`copy action plugin <https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/action/copy.py#L329>`_」の「``_original_basename``」を参照してください。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:390
msgid "_ansible_no_log"
msgstr "_ansible_no_log"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:392
msgid "Boolean. Set to True whenever a parameter in a task or play specifies ``no_log``. Any module that calls :py:meth:`AnsibleModule.log` handles this automatically. If a module implements its own logging then it needs to check this value. To access in a module, instantiate an ``AnsibleModule`` and then check the value of :attr:`AnsibleModule.no_log`."
msgstr "ブール値。タスクまたはプレイのパラメーターを ``no_log`` に指定した場合は常に True に設定します。:py:meth:`AnsibleModule.log` を呼び出すモジュールが自動的にこれを処理します。モジュールがその独自のロギングを実装した場合は、この値を確認する必要があります。モジュールにアクセスするには、``AnsibleModule`` をインスタンス化して、:attr:`AnsibleModule.no_log` の値を確認します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:397
msgid "``no_log`` specified in a module's argument_spec is handled by a different mechanism."
msgstr "モジュールの argument_spec で指定された ``no_log`` は別のメカニズムで処理されます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:400
msgid "_ansible_debug"
msgstr "_ansible_debug"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:402
msgid "Boolean. Turns more verbose logging on or off and turns on logging of external commands that the module executes. If a module uses :py:meth:`AnsibleModule.debug` rather than :py:meth:`AnsibleModule.log` then the messages are only logged if ``_ansible_debug`` is set to ``True``. To set, add ``debug: True`` to :file:`ansible.cfg` or set the environment variable :envvar:`ANSIBLE_DEBUG`. To access in a module, instantiate an ``AnsibleModule`` and access :attr:`AnsibleModule._debug`."
msgstr "ブール値。詳細なロギングをオンまたはオフにし、モジュールが実行する外部コマンドのロギングを有効にします。モジュールが :py:meth:`AnsibleModule.log` ではなく :py:meth:`AnsibleModule.debug` を使用する場合は、``_ansible_debug`` が ``True`` に設定されている場合にのみメッセージがログに記録されます。設定するには、``debug: True`` を :file:`ansible.cfg` に追加するか、環境変数 :envvar:`ANSIBLE_DEBUG` を設定します。モジュールにアクセスするには、``AnsibleModule`` をインスタンス化し、:attr:`AnsibleModule._debug` にアクセスします。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:411
msgid "_ansible_diff"
msgstr "_ansible_diff"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:413
msgid "Boolean. If a module supports it, tells the module to show a unified diff of changes to be made to templated files. To set, pass the ``--diff`` command line option. To access in a module, instantiate an `AnsibleModule` and access :attr:`AnsibleModule._diff`."
msgstr "ブール値。モジュールがサポートする場合は、モジュールに対し、テンプレート化されたファイルに加えられた変更の差異を統合するようにモジュールに指示します。設定するには、``--diff`` コマンドラインオプションを渡します。モジュールにアクセスするには、`AnsibleModule` をインスタンス化して、:attr:`AnsibleModule._diff` にアクセスしてください。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:419
msgid "_ansible_verbosity"
msgstr "_ansible_verbosity"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:421
msgid "Unused. This value could be used for finer grained control over logging."
msgstr "未使用。この値は、ログをより細かく制御するために使用できます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:424
msgid "_ansible_selinux_special_fs"
msgstr "_ansible_selinux_special_fs"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:426
msgid "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`:"
msgstr "一覧。特別な SELinux コンテキストを持つ必要があるファイルシステムの名前。名前はファイル (属性の変更、移動、コピー) で操作する `AnsibleModule` メソッドによって使用されます。設定するには、:file:`ansible.cfg` に、ファイル名のコンマ区切りの文字列を追加します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:436
msgid "Most modules can use the built-in ``AnsibleModule`` methods to manipulate files. To access in a module that needs to know about these special context filesystems, instantiate an ``AnsibleModule`` and examine the list in :attr:`AnsibleModule._selinux_special_fs`."
msgstr "ほとんどのモジュールは、ファイルを操作する組み込み ``AnsibleModule`` メソッドを使用できます。これらの特別なコンテキストファイルシステムについて知る必要があるモジュールにアクセスするには、``AnsibleModule`` をインスタンス化し、:attr:`AnsibleModule._selinux_special_fs` でリストを調べます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:440
msgid "This replaces :attr:`ansible.module_utils.basic.SELINUX_SPECIAL_FS` from :ref:`module_replacer`. In module replacer it was a comma separated string of filesystem names. Under Ansiballz it's an actual list."
msgstr "これにより、:ref:`module_replacer` の :attr:`ansible.module_utils.basic.SELINUX_SPECIAL_FS` を置き換えます。モジュール置換は、ファイル名のコンマ区切りの文字列でした。Ansiballz は、実際のリストになります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:447
msgid "_ansible_syslog_facility"
msgstr "_ansible_syslog_facility"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:449
msgid "This parameter controls which syslog facility Ansible module logs to. To set, change the ``syslog_facility`` value in :file:`ansible.cfg`. Most modules should just use :meth:`AnsibleModule.log` which will then make use of this. If a module has to use this on its own, it should instantiate an `AnsibleModule` and then retrieve the name of the syslog facility from :attr:`AnsibleModule._syslog_facility`. The Ansiballz code is less hacky than the old :ref:`module_replacer` code:"
msgstr "このパラメーターは、Ansible モジュールがどの syslog 機能にログを記録するかを制御します。設定するには、:file:`ansible.cfg` の ``syslog_facility`` の値を変更します。多くのモジュールは、これを利用する :meth:`AnsibleModule.log` のみを使用する必要があります。モジュールが独自にこれを使用する必要がある場合は、`AnsibleModule` をインスタンス化して、:attr:`AnsibleModule._syslog_facility` から syslog 機能の名前を取得する必要があります。Ansiballz コードは古い :ref:`module_replacer` コードよりもハッキングされません。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:470
msgid "_ansible_version"
msgstr "_ansible_version"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:472
msgid "This parameter passes the version of Ansible that runs the module. To access it, a module should instantiate an `AnsibleModule` and then retrieve it from :attr:`AnsibleModule.ansible_version`. This replaces :attr:`ansible.module_utils.basic.ANSIBLE_VERSION` from :ref:`module_replacer`."
msgstr "このパラメーターは、モジュールを実行する Ansible のバージョンを渡します。これにアクセスするために、モジュールは `AnsibleModule` をインスタンス化し、:attr:`AnsibleModule.ansible_version` から取得する必要があります。これは、:ref:`module_replacer` の :attr:`ansible.module_utils.basic.ANSIBLE_VERSION` を置き換えます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:484
msgid "Module return values & Unsafe strings"
msgstr "モジュール戻り値と安全でない文字列"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:486
msgid "At the end of a module's execution, it formats the data that it wants to return as a JSON string and prints the string to its stdout. The normal action plugin receives the JSON string, parses it into a Python dictionary, and returns it to the executor."
msgstr "モジュールの実行の最後に、返したいデータを JSON 文字列として形式化し、その文字列を標準出力 (stdout) に出力します。通常の action プラグインは JSON 文字列を受け取り、Python ディクショナリーに解析してエクゼキューターに返します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:488
msgid "If Ansible templated every string return value, it would be vulnerable to an attack from users with access to managed nodes. If an unscrupulous user disguised malicious code as Ansible return value strings, and if those strings were then templated on the controller, Ansible could execute arbitrary code. To prevent this scenario, Ansible marks all strings inside returned data as ``Unsafe``, emitting any Jinja2 templates in the strings verbatim, not expanded by Jinja2."
msgstr "Ansible がすべての文字列の戻り値をテンプレート化すると、管理ノードにアクセスできるユーザーからの攻撃に対して脆弱になります。悪意のあるユーザーが悪意のあるコードを Ansible の戻り値の文字列として偽装し、そのような文字列がコントローラー上でテンプレート化されると、Ansible が任意のコードを実行する可能性があります。このシナリオを防ぐために、Ansible は戻り値のデータ内のすべての文字列を ``Unsafe`` と表示し、文字列内の Jinja2 テンプレートを Jinja2 で展開せずにそのままエミットします。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:490
msgid "Strings returned by invoking a module through ``ActionPlugin._execute_module()`` are automatically marked as ``Unsafe`` by the normal action plugin. If another action plugin retrieves information from a module through some other means, it must mark its return data as ``Unsafe`` on its own."
msgstr "``ActionPlugin._execute_module()`` を介してモジュールを呼び出して返された文字列には、通常の action プラグインによって自動的に ``Unsafe`` というマークが付きます。別の action プラグインが他の方法でモジュールから情報を取得した場合は、その action プラグイン自身がその戻り値に ``Unsafe`` と表示する必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:492
msgid "In case a poorly-coded action plugin fails to mark its results as \"Unsafe,\" Ansible audits the results again when they are returned to the executor, marking all strings as ``Unsafe``. The normal action plugin protects itself and any other code that it calls with the result data as a parameter. The check inside the executor protects the output of all other action plugins, ensuring that subsequent tasks run by Ansible will not template anything from those results either."
msgstr "不適切にコーディングされた action プラグインが結果を「Unsafe」と表示しなかった場合、Ansible はエグゼキューターに返される際に結果を再度監査し、すべての文字列を ``Unsafe`` と表示します。通常の action プラグインは、自身と、結果データをパラメーターとして呼び出すその他のコードを保護します。エクゼキュータ内のチェックは、他のすべての action プラグインの出力を保護し、Ansible が実行する後続のタスクがこれらの結果から何かをテンプレート化することがないようにします。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:498
msgid "Special considerations"
msgstr "特別な考慮事項"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:503
msgid "Pipelining"
msgstr "パイプライン"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:505
msgid "Ansible can transfer a module to a remote machine in one of two ways:"
msgstr "Ansible は、以下のいずれかの方法で、モジュールをリモートマシンに転送できます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:507
msgid "it can write out the module to a temporary file on the remote host and then use a second connection to the remote host to execute it with the interpreter that the module needs"
msgstr "これは、リモートホストの一時ファイルにモジュールを書き込むことができ、次にリモートホストへの 2 番目の接続を使用して、モジュールが必要とするインタープリターでこれを実行します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:510
msgid "or it can use what's known as pipelining to execute the module by piping it into the remote interpreter's stdin."
msgstr "または、パイプラインと呼ばれるものを使用して、モジュールをリモートインタープリターの stdin にパイプすることでモジュールを実行できます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:513
msgid "Pipelining only works with modules written in Python at this time because Ansible only knows that Python supports this mode of operation. Supporting pipelining means that whatever format the module payload takes before being sent over the wire must be executable by Python via stdin."
msgstr "パイプライン処理は、現時点では Python で記述されたモジュールでのみ機能します。これは、Python がこの操作モードをサポートしていることのみを Ansible が認識しているためです。パイプライン化をサポートするということは、モジュールペイロードがネットワーク経由で送信される前に取る形式が何であれ、Python が stdin を介して実行可能でなければならないことを意味します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:521
msgid "Why pass args over stdin?"
msgstr "標準入力 (stdin) で引数を渡す理由"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:523
msgid "Passing arguments via stdin was chosen for the following reasons:"
msgstr "以下の理由により、標準入力で引数を渡すことが選択されました。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:525
msgid "When combined with :ref:`ANSIBLE_PIPELINING`, this keeps the module's arguments from temporarily being saved onto disk on the remote machine. This makes it harder (but not impossible) for a malicious user on the remote machine to steal any sensitive information that may be present in the arguments."
msgstr ":ref:`ANSIBLE_PIPELINING` と組み合わせると、モジュールの引数をリモートマシン上のディスクに一時的に保存したままにします。これにより、リモートマシン上の悪意のあるユーザーが引数に存在する可能性のある機密情報を盗むのが困難になります (不可能ではありません)。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:529
msgid "Command line arguments would be insecure as most systems allow unprivileged users to read the full commandline of a process."
msgstr "ほとんどのシステムでは、権限のないユーザーがプロセスのコマンドライン全体を読むことを許可されているため、コマンドライン引数は安全ではありません。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:531
msgid "Environment variables are usually more secure than the commandline but some systems limit the total size of the environment. This could lead to truncation of the parameters if we hit that limit."
msgstr "環境変数は通常コマンドラインより安全ですが、環境の合計サイズを制限するシステムもあります。これにより、パラメーターが上限に達すると、パラメーターが切り捨てられる可能性があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:539
msgid "AnsibleModule"
msgstr "AnsibleModule"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:544
msgid "Argument spec"
msgstr "引数の仕様"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:546
msgid "The ``argument_spec`` provided to ``AnsibleModule`` defines the supported arguments for a module, as well as their type, defaults and more."
msgstr "``AnsibleModule`` に提供される ``argument_spec`` は、モジュールでサポートされる引数、その型、デフォルトなどを定義します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:548
msgid "Example ``argument_spec``:"
msgstr "``argument_spec`` の例:"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:564
msgid "This section will discuss the behavioral attributes for arguments:"
msgstr "本セクションでは、引数の動作属性を説明します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:568
msgid "``type`` allows you to define the type of the value accepted for the argument. The default value for ``type`` is ``str``. Possible values are:"
msgstr "``type`` では、引数に受け入れられる値の型を定義できます。``type`` のデフォルト値は ``str`` です。可能な値は次のとおりです。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:570
msgid "str"
msgstr "str"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:571
msgid "list"
msgstr "list"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:572
msgid "dict"
msgstr "dict"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:573
msgid "bool"
msgstr "bool"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:574
msgid "int"
msgstr "int"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:575
msgid "float"
msgstr "float"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:576
msgid "path"
msgstr "path"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:577
msgid "raw"
msgstr "raw"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:578
msgid "jsonarg"
msgstr "jsonarg"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:579
#: ../../rst/dev_guide/style_guide/index.rst:152
msgid "json"
msgstr "json"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:580
msgid "bytes"
msgstr "bytes"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:581
msgid "bits"
msgstr "bits"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:583
msgid "The ``raw`` type, performs no type validation or type casting, and maintains the type of the passed value."
msgstr "``raw`` 型で、型の検証や型キャストを行わず、渡された値の型を保持します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:587
msgid "``elements`` works in combination with ``type`` when ``type='list'``. ``elements`` can then be defined as ``elements='int'`` or any other type, indicating that each element of the specified list should be of that type."
msgstr "``elements`` は、``type='list'`` の時に ``type`` と組み合わせて動作します。``elements`` は ``elements='int'`` などの型で定義することができ、指定されたリストの各要素がその型であることを示します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:591
msgid "The ``default`` option allows sets a default value for the argument for the scenario when the argument is not provided to the module. When not specified, the default value is ``None``."
msgstr "``default`` オプションは、引数がモジュールに提供されていない場合のシナリオの引数のデフォルト値を設定します。指定しない場合、デフォルト値は ``None`` です。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "fallback"
msgstr "fallback"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:595
msgid "``fallback`` accepts a ``tuple`` where the first argument is a callable (function) that will be used to perform the lookup, based on the second argument. The second argument is a list of values to be accepted by the callable."
msgstr "``fallback`` は、第 1 引数に、第 2 引数に基づいて検索を実行するのに使用する callable (関数) の ``tuple`` を受け入れます。2 つ目の引数は、callable オブジェクトによって受け入れられる値のリストです。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:597
msgid "The most common callable used is ``env_fallback`` which will allow an argument to optionally use an environment variable when the argument is not supplied."
msgstr "最も一般的に使用されている callable は ``env_fallback`` で、これは引数が設定されていない場合に任意で環境変数を使用できるようにします。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:607
msgid "``choices`` accepts a list of choices that the argument will accept. The types of ``choices`` should match the ``type``."
msgstr "``choices`` は、引数が受け入れる選択肢のリストを受け入れます。``choices`` の型は、``type`` と一致している必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:611
msgid "``required`` accepts a boolean, either ``True`` or ``False`` that indicates that the argument is required. When not specified, ``required`` defaults to ``False``. This should not be used in combination with ``default``."
msgstr "``required`` ブール値 (``True`` または ``False`` のいずれか) も受け入れます。これは、引数が必要であることを示しています。指定しない場合、``required`` のデフォルトは ``False`` になります。これは、``default`` と組み合わせて使用しないでください。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "no_log"
msgstr "no_log"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:615
msgid "``no_log`` accepts a boolean, either ``True`` or ``False``, that indicates explicitly whether or not the argument value should be masked in logs and output."
msgstr "``no_log`` には、引数の値がログや出力でマスクされるべきかどうかを明示的に示すブール値 (``True`` または ``False``) を使用できます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:618
msgid "In the absence of ``no_log``, if the parameter name appears to indicate that the argument value is a password or passphrase (such as \"admin_password\"), a warning will be shown and the value will be masked in logs but **not** output. To disable the warning and masking for parameters that do not contain sensitive information, set ``no_log`` to ``False``."
msgstr "``no_log`` がない場合は、パラメーター名が、引数の値がパスワードやパスフレーズであることを示しているように見える場合 (「admin_password」など)、警告が表示され、値はログでマスクされますが、**出力されません**。機密情報を含まないパラメーターの警告とマスキングを無効にするには、``no_log`` を ``False`` に設定します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:622
msgid "``aliases`` accepts a list of alternative argument names for the argument, such as the case where the argument is ``name`` but the module accepts ``aliases=['pkg']`` to allow ``pkg`` to be interchangeably with ``name``"
msgstr "``aliases`` では、引数の代替引数名のリストが使用できます。たとえば、引数は ``name`` ですが、モジュールが ``aliases=['pkg']`` を受け付けて、``pkg`` を ``name`` と互換性を持たせるようにしています。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:626
msgid "``options`` implements the ability to create a sub-argument_spec, where the sub options of the top level argument are also validated using the attributes discussed in this section. The example at the top of this section demonstrates use of ``options``. ``type`` or ``elements`` should be ``dict`` is this case."
msgstr "``options`` は、上位レベルの引数のサブオプションもこのセクションで説明した属性を使用して検証される sub-argument_spec を作成する機能を実装しています。このセクションの冒頭にある例は、``options`` の使用を示しています。ここでは、``type`` または ``elements`` は ``dict`` である必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "apply_defaults"
msgstr "apply_defaults"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:630
msgid "``apply_defaults`` works alongside ``options`` and allows the ``default`` of the sub-options to be applied even when the top-level argument is not supplied."
msgstr "``apply_defaults`` は、``options`` と並んで動作し、上位レベルの引数が指定されていない場合でもサブオプションの ``デフォルト`` を適用できるようにします。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:632
msgid "In the example of the ``argument_spec`` at the top of this section, it would allow ``module.params['top_level']['second_level']`` to be defined, even if the user does not provide ``top_level`` when calling the module."
msgstr "このセクションの冒頭にある ``argument_spec`` の例では、ユーザーがモジュールを呼び出すときに ``top_level`` を指定しなかった場合でも、``module.params['top_level']['second_level']`` を定義できるようにします。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "removed_in_version"
msgstr "removed_in_version"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:636
msgid "``removed_in_version`` indicates which version of ansible-core or a collection a deprecated argument will be removed in. Mutually exclusive with ``removed_at_date``, and must be used with ``removed_from_collection``."
msgstr "``removed_in_version`` は、非推奨の引数が削除される ansible-core またはコレクションのバージョンを示します。``removed_at_date`` で相互に排他となり、``removed_from_collection`` で使用する必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "removed_at_date"
msgstr "removed_at_date"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:650
msgid "``removed_at_date`` indicates that a deprecated argument will be removed in a minor ansible-core release or major collection release after this date. Mutually exclusive with ``removed_in_version``, and must be used with ``removed_from_collection``."
msgstr "``removed_at_date`` は、非推奨の引数が、この日付以降のマイナーな ansible-core リリースまたはメジャーコレクションリリースで削除されることを示します。``removed_in_version`` と相互に排他的であり、``removed_from_collection`` と一緒に使用する必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "removed_from_collection"
msgstr "removed_from_collection"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:664
msgid "Specifies which collection (or ansible-core) deprecates this deprecated argument. Specify ``ansible.builtin`` for ansible-core, or the collection's name (format ``foo.bar``). Must be used with ``removed_in_version`` or ``removed_at_date``."
msgstr "この非推奨の引数を非推奨にするコレクション (または ansible-core) を指定します。ansible-core には ``ansible.builtin``、またはコレクションの名前 (``foo.bar`` の形式) を指定します。``removed_in_version`` または ``removed_at_date`` と共に使用する必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "deprecated_aliases"
msgstr "deprecated_aliases"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:668
msgid "Deprecates aliases of this argument. Must contain a list or tuple of dictionaries having some the following keys:"
msgstr "この引数のエイリアスを非推奨にします。以下のキーを持つディクショナリーのリストまたはタプルが含まれます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "name"
msgstr "name"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:672
msgid "The name of the alias to deprecate. (Required.)"
msgstr "非推奨にするエイリアスの名前 (必須)"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
#: ../../rst/dev_guide/testing/sanity/update-bundled.rst
msgid "version"
msgstr "version"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:676
msgid "The version of ansible-core or the collection this alias will be removed in. Either ``version`` or ``date`` must be specified."
msgstr "ansible-core、またはこのエイリアスは削除されるコレクションのバージョン。``version`` または ``date`` のいずれかを指定する必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "date"
msgstr "date"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:680
msgid "The a date after which a minor release of ansible-core or a major collection release will no longer contain this alias.. Either ``version`` or ``date`` must be specified."
msgstr "ansible-core のマイナーリリースまたはメジャーコレクションリリースにこのエイリアスが含まれなくなった日付。``version`` または ``date`` のいずれかを指定する必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "collection_name"
msgstr "collection_name"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:684
msgid "Specifies which collection (or ansible-core) deprecates this deprecated alias. Specify ``ansible.builtin`` for ansible-core, or the collection's name (format ``foo.bar``). Must be used with ``version`` or ``date``."
msgstr "この非推奨のエイリアスを非推奨にするコレクション (または ansible-core) を指定します。ansible-core には ``ansible.builtin``、またはコレクションの名前 (``foo.bar`` の形式) を指定します。``version`` または ``date`` と共に使用する必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:686
msgid "Examples:"
msgstr "例:"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "mutually_exclusive"
msgstr "mutually_exclusive"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:710
msgid "If ``options`` is specified, ``mutually_exclusive`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`."
msgstr "``options`` を指定すると、``mutually_exclusive`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "required_together"
msgstr "required_together"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:714
msgid "If ``options`` is specified, ``required_together`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`."
msgstr "``options`` を指定すると、``required_together`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "required_one_of"
msgstr "required_one_of"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:718
msgid "If ``options`` is specified, ``required_one_of`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`."
msgstr "``options`` を指定すると、``required_one_of`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "required_if"
msgstr "required_if"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:722
msgid "If ``options`` is specified, ``required_if`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`."
msgstr "``options`` を指定すると、``required_if`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst
msgid "required_by"
msgstr "required_by"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:726
msgid "If ``options`` is specified, ``required_by`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`."
msgstr "``options`` を指定すると、``required_by`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:732
msgid "Dependencies between module options"
msgstr "モジュールオプションの依存関係"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:734
msgid "The following are optional arguments for ``AnsibleModule()``:"
msgstr "以下は、``AnsibleModule()`` の任意の引数です。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:750
msgid "Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names which are mutually exclusive. If more than one options of a list are specified together, Ansible will fail the module with an error."
msgstr "文字列シーケンスのシーケンス (リストまたはタプル) です。文字列のシーケンスは相互排他的なオプション名のリストです。リストの複数のオプションを指定すると、Ansible はエラーを出してモジュールに失敗します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:761
msgid "In this example, the options ``path`` and ``content`` must not specified at the same time. Also the options ``repository_url`` and ``repository_filename`` must not be specified at the same time. But specifying ``path`` and ``repository_url`` is accepted."
msgstr "この例では、``path`` オプションと ``content`` オプションは同時に指定しないでください。``repository_url`` オプションと ``repository_filename`` オプションを同時に指定することはできません。ただし、``path`` および ``repository_url`` を指定することはできます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:763
msgid "To ensure that precisely one of two (or more) options is specified, combine ``mutually_exclusive`` with ``required_one_of``."
msgstr "正確に 2 つのオプション (または複数の) オプションのいずれかを指定するようにするには、``mutually_exclusive`` と ``required_one_of`` を組み合わせます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:767
msgid "Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names which are must be specified together. If at least one of these options are specified, the other ones from the same sequence must all be present."
msgstr "文字列のシーケンスのシーケンス (リストまたはタプル) である必要があります。文字列のすべてのシーケンスは、一緒に指定する必要があるオプション名のリストです。これらのオプションが少なくとも 1 つ指定されている場合は、同じシーケンスの他のオプションがすべて存在している必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:777
msgid "In this example, if one of the options ``file_path`` or ``file_hash`` is specified, Ansible will fail the module with an error if the other one is not specified."
msgstr "この例では、``file_path`` または ``file_hash`` のいずれかのオプションを指定し、他のオプションが指定していないと、Ansible はエラーを出してモジュールに失敗します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:781
msgid "Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names from which at least one must be specified. If none one of these options are specified, Ansible will fail module execution."
msgstr "文字列のシーケンスのシーケンス (リストまたはタプル) である必要があります。文字列のすべてのシーケンスは、少なくとも 1 つを指定する必要があるオプション名のリストです。これらのオプションがいずれも指定されていない場合、Ansible はモジュールの実行に失敗します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:791
msgid "In this example, at least one of ``path`` and ``content`` must be specified. If none are specified, execution will fail. Specifying both is explicitly allowed; to prevent this, combine ``required_one_of`` with ``mutually_exclusive``."
msgstr "この例では、``path`` および ``content`` のいずれかを指定する必要があります。指定しないと、実行が失敗します。両方の値を指定すると、明示的に許可されます。これを回避するには、``required_one_of`` と ``mutually_exclusive`` を組み合わせます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:795
msgid "Must be a sequence of sequences. Every inner sequence describes one conditional dependency. Every sequence must have three or four values. The first two values are the option's name and the option's value which describes the condition. The further elements of the sequence are only needed if the option of that name has precisely this value."
msgstr "一連のシーケンスのシーケンスである必要があります。すべての内部シーケンスでは、条件の依存関係を 1 つ説明します。すべてのシーケンスには、値が 3 つまたは 4 つ必要です。最初の 2 つの値は、オプション名と、その条件を説明するオプションの値です。シーケンスの追加要素は、その名前のオプションが正確にこの値を持っている場合にのみ必要です。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:797
msgid "If you want that all options in a list of option names are specified if the condition is met, use one of the following forms:"
msgstr "条件が満たされた場合にオプション名のリスト内のオプションをすべて指定する場合は、次のいずれかの形式を使用します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:804
msgid "If you want that at least one option of a list of option names is specified if the condition is met, use the following form:"
msgstr "条件が満たされた場合にオプション名の一覧のオプションを 1 つ以上指定する場合は、以下の形式を使用します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:819
msgid "In this example, if the user specifies ``state=present``, at least one of the options ``path`` and ``content`` must be supplied (or both). To make sure that precisely one can be specified, combine ``required_if`` with ``mutually_exclusive``."
msgstr "この例では、ユーザーが ``state=present`` を指定している場合は、``path`` と ``content`` のいずれか (または両方) のオプションを指定する必要があります。必ず指定するようにするには、``required_if`` と ``mutually_exclusive`` を組み合わせます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:821
msgid "On the other hand, if ``force`` (a boolean parameter) is set to ``true``, ``yes`` etc., both ``force_reason`` and ``force_code`` must be specified."
msgstr "一方、``force`` (ブール値パラメーター) が ``true``、``yes`` などに設定されている場合は、``force_reason`` と ``force_code`` の両方を指定する必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:825
msgid "Must be a dictionary mapping option names to sequences of option names. If the option name in a dictionary key is specified, the option names it maps to must all also be specified. Note that instead of a sequence of option names, you can also specify one single option name."
msgstr "オプション名のシーケンスへのディクショナリーマッピングオプション名である必要があります。ディクショナリーキーでオプション名を指定すると、そのオプション名をすべて指定する必要があります。オプション名のシーケンスの代わりに、オプションの名前を 1 つ指定することもできます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:836
msgid "In the example, if ``force`` is specified, ``force_reason`` must also be specified. Also, if ``path`` is specified, then three three options ``mode``, ``owner`` and ``group`` also must be specified."
msgstr "この例では、``force`` が指定されている場合は、``force_reason`` も指定する必要があります。また、``path`` が指定されている場合は、3 つのオプション ``mode``、``owner``、および ``group`` も指定する必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:839
msgid "Declaring check mode support"
msgstr "チェックモードのサポートの宣言"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:841
msgid "To declare that a module supports check mode, supply ``supports_check_mode=True`` to the ``AnsibleModule()`` call:"
msgstr "モジュールが確認モードをサポートすることを宣言するには、``AnsibleModule()`` 呼び出しに ``supports_check_mode=True`` を指定します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:847
msgid "The module can determine whether it is called in check mode by checking the boolean value ``module.check_mode``. If it evaluates to ``True``, the module must take care not to do any modification."
msgstr "モジュールは、ブール値 ``module.check_mode`` を確認することで、チェックモードで呼び出されるかどうかを判断できます。``True`` に評価する場合、モジュールは変更を行わないようにする必要があります。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:849
msgid "If ``supports_check_mode=False`` is specified, which is the default value, the module will exit in check mode with ``skipped=True`` and message ``remote module (<insert module name here>) does not support check mode``."
msgstr "``supports_check_mode=False`` が指定されている場合 (デフォルト値)、モジュールはチェックモードで ``skipped=True`` および ``remote module (<insert module name here>) does not support check mode`` メッセージで終了します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:852
msgid "Adding file options"
msgstr "ファイルオプションの追加"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:854
msgid "To declare that a module should add support for all common file options, supply ``add_file_common_args=True`` to the ``AnsibleModule()`` call:"
msgstr "モジュールがすべての共通ファイルオプションのサポートを追加することを宣言するには、``add_file_common_args=True`` を ``AnsibleModule()`` 呼び出しに指定します。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:860
msgid "You can find `a list of all file options here <https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/doc_fragments/files.py>`_. It is recommended that you make your ``DOCUMENTATION`` extend the doc fragment ``ansible.builtin.files`` (see :ref:`module_docs_fragments`) in this case, to make sure that all these fields are correctly documented."
msgstr "`ここで、ファイルオプションの一覧 <https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/doc_fragments/files.py>`_ を確認できます。今回は、``DOCUMENTATION`` がドキュメントフラグメント ``ansible.builtin.files`` (:ref:`module_docs_fragments` を参照) を拡張し、これらのフィールドがすべて正しく文書化されていることを確認することが推奨されます。"

#: ../../rst/dev_guide/developing_program_flow_modules.rst:862
msgid "The helper functions ``module.load_file_common_arguments()`` and ``module.set_fs_attributes_if_different()`` can be used to handle these arguments for you:"
msgstr "ヘルパー関数 ``module.load_file_common_arguments()`` および ``module.set_fs_attributes_if_different()`` を使用して、以下の引数を扱うことができます。"

#: ../../rst/dev_guide/developing_python_3.rst:5
msgid "Ansible and Python 3"
msgstr "Ansible および Python 3"

#: ../../rst/dev_guide/developing_python_3.rst:7
msgid "The ``ansible-core`` code runs Python 3 (for specific versions check :ref:`Control Node Requirements <control_node_requirements>` Contributors to ``ansible-core`` and to Ansible Collections should be aware of the tips in this document so that they can write code that will run on the same versions of Python as the rest of Ansible."
msgstr "``ansible-core`` コードは Python3 を実行します (特定のバージョンについては:ref:`Control Node Requirements <control_node_requirements>` を確認してください)。``ansible-core`` および Ansible コレクションへのコントリビューターは、残りの Ansible と同じバージョンの Python で実行されるコードを記述できるように、このドキュメントに記載されているヒントを把握しておく必要があります。"

#: ../../rst/dev_guide/developing_python_3.rst:14
msgid "We do have some considerations depending on the types of Ansible code:"
msgstr "Ansible コードのタイプによっては、いくつかの考慮事項があります。"

#: ../../rst/dev_guide/developing_python_3.rst:16
msgid "controller-side code - code that runs on the machine where you invoke :command:`/usr/bin/ansible`, only needs to support the controller's Python versions."
msgstr "コントローラー側のコード - :command:`/usr/bin/ansible` を呼び出すマシンで実行されるコード。コントローラーの Python バージョンのみをサポートする必要があります。"

#: ../../rst/dev_guide/developing_python_3.rst:17
msgid "modules - the code which Ansible transmits to and invokes on the managed machine. Modules need to support the 'managed node' Python versions, with some exceptions."
msgstr "モジュール - Ansible が管理対象マシンに送信して呼び出すコード。一部の例外を除き、モジュールは「管理対象ノード」の Python バージョンをサポートする必要があります。"

#: ../../rst/dev_guide/developing_python_3.rst:18
msgid "shared ``module_utils`` code - the common code that is  used by modules to perform tasks and sometimes used by controller-side code as well. Shared ``module_utils`` code needs to support the same range of Python as the modules."
msgstr "共有されている ``module_utils`` コード - タスクを実行するためにモジュールが使用する一般的なコードで、コントローラー側のコードで使用されることもあります。共有されている ``module_utils`` コードは、モジュールと同じ範囲の Python をサポートする必要があります。"

#: ../../rst/dev_guide/developing_python_3.rst:20
msgid "However, the three types of code do not use the same string strategy. If you're developing a module or some ``module_utils`` code, be sure to read the section on string strategy carefully."
msgstr "ただし、この 3 種類のコードで同じ文字列ストラテジーが使用されているわけではありません。モジュールまたはいくつかの ``module_utils`` コードを開発している場合は、文字列ストラテジーのセクションを注意してお読みください。"

#: ../../rst/dev_guide/developing_python_3.rst:26
msgid "Minimum version of Python 3.x and Python 2.x"
msgstr "Python 3.x および Python 2.x の最小バージョン"

#: ../../rst/dev_guide/developing_python_3.rst:28
msgid "See :ref:`Control Node Requirements <control_node_requirements>` and :ref:`Managed Node Requirements <managed_node_requirements>` for the specific versions supported."
msgstr "サポート対象のバージョンは、:ref:`Control Node Requirements <control_node_requirements>` および :ref:`Managed Node Requirements <managed_node_requirements>` を参照してください。"

#: ../../rst/dev_guide/developing_python_3.rst:31
msgid "Your custom modules can support any version of Python (or other languages) you want, but the above are the requirements for the code contributed to the Ansible project."
msgstr "カスタムモジュールは、任意のバージョンの Python (またはその他の言語) をサポートできますが、上記は Ansible プロジェクトに提供されるコードの要件です。"

#: ../../rst/dev_guide/developing_python_3.rst:34
msgid "Developing Ansible code that supports Python 2 and Python 3"
msgstr "Python 2 および Python 3 をサポートする Ansible コードの開発"

#: ../../rst/dev_guide/developing_python_3.rst:36
msgid "The best place to start learning about writing code that supports both Python 2 and Python 3 is `Lennart Regebro's book: Porting to Python 3 <http://python3porting.com/>`_. The book describes several strategies for porting to Python 3. The one we're using is `to support Python 2 and Python 3 from a single code base <http://python3porting.com/strategies.html#python-2-and-python-3-without-conversion>`_"
msgstr "Python 2 と Python 3 の両方をサポートするコードの記述について学び始めるのに最適なのは、`Lennart Regebro の著書: Porting to Python 3 <http://python3porting.com/>`_ です。本書では、Python 3 に移植するためのいくつかのストラテジーが説明されています。Ansible で使用しているのは、`単一のコードベースから Python 2 および Python 3 をサポートするため <http://python3porting.com/strategies.html#python-2-and-python-3-without-conversion>`_ です。"

#: ../../rst/dev_guide/developing_python_3.rst:43
msgid "Understanding strings in Python 2 and Python 3"
msgstr "Python 2 および Python 3 の文字列を理解"

#: ../../rst/dev_guide/developing_python_3.rst:45
msgid "Python 2 and Python 3 handle strings differently, so when you write code that supports Python 3 you must decide what string model to use.  Strings can be an array of bytes (like in C) or they can be an array of text.  Text is what we think of as letters, digits, numbers, other printable symbols, and a small number of unprintable \"symbols\" (control codes)."
msgstr "Python 2 と Python 3 では文字列の扱いが異なるため、Python 3 をサポートするコードを作成するときは、どのような文字列モデルを使用するかを決める必要があります。文字列は (C 言語のように) バイトの配列にすることもできますし、テキストの配列にすることもできます。ここでの「テキスト」とは、文字、数字 (digit または number)、その他の印刷可能な記号、および少数の印刷不可能な「記号」(制御コード) になります。"

#: ../../rst/dev_guide/developing_python_3.rst:51
msgid "In Python 2, the two types for these (:class:`str <python:str>` for bytes and :func:`unicode <python:unicode>` for text) are often used interchangeably.  When dealing only with ASCII characters, the strings can be combined, compared, and converted from one type to another automatically.  When non-ASCII characters are introduced, Python 2 starts throwing exceptions due to not knowing what encoding the non-ASCII characters should be in."
msgstr "Python 2 では、これらの 2 つのタイプ (バイト単位の場合は :class:`str <python:str>`、テキストの場合は :func:`unicode <python:unicode>`) が、しばしば同じ意味で使用されます。ASCII 文字のみを処理する場合は、文字列を組み合わせて比較し、あるタイプから別のタイプに自動的に変換できます。非 ASCII 文字が導入されると、Python 2 は、非 ASCII 文字がどのエンコーディングに含まれるべきかわからないために例外を出力し始めます。"

#: ../../rst/dev_guide/developing_python_3.rst:58
msgid "Python 3 changes this behavior by making the separation between bytes (:class:`bytes <python3:bytes>`) and text (:class:`str <python3:str>`) more strict.  Python 3 will throw an exception when trying to combine and compare the two types.  The programmer has to explicitly convert from one type to the other to mix values from each."
msgstr "Python 3 は、バイト (:class:`bytes <python3:bytes>`) とテキスト (:class:`str <python3:str>`) を分離することでこの動作を変更します。Python 3 は 2 つのタイプの結合と比較を試みる際に例外を出力させます。プログラマーは、ある型から別の型に変換し、混在させる必要があります。"

#: ../../rst/dev_guide/developing_python_3.rst:63
msgid "In Python 3 it's immediately apparent to the programmer when code is mixing the byte and text types inappropriately, whereas in Python 2, code that mixes those types may work until a user causes an exception by entering non-ASCII input. Python 3 forces programmers to proactively define a strategy for working with strings in their program so that they don't mix text and byte strings unintentionally."
msgstr "Python 3 では、プログラマーは、コードがバイト型とテキスト型を不適切に混合していることがすぐに分かりますが、Python 2 では、ユーザーが非 ASCII 入力を入力して例外が発生するまでは、これらの型を混合しているコードが動作するかもしれません。Python 3 では、プログラマーが意図せずにテキスト文字列とバイト文字列を混在させないように、プログラムの中で文字列を扱うためのストラテジーを積極的に定義することを強制しています。"

#: ../../rst/dev_guide/developing_python_3.rst:69
msgid "Ansible uses different strategies for working with strings in controller-side code, in :ref: `modules <module_string_strategy>`, and in :ref:`module_utils <module_utils_string_strategy>` code."
msgstr "Ansible は、:ref:`modules <module_string_strategy>` コードおよび :ref:`module_utils <module_utils_string_strategy>` コードのコントローラー側のコードで文字列を操作するためにさまざまなストラテジーを使用します。"

#: ../../rst/dev_guide/developing_python_3.rst:75
msgid "Controller string strategy: the Unicode Sandwich"
msgstr "コントローラー文字列ストラテジー: Unicode Sandwich"

#: ../../rst/dev_guide/developing_python_3.rst:77
msgid "Until recently ``ansible-core`` supported Python 2.x and followed this strategy, known as the Unicode Sandwich (named after Python 2's :func:`unicode  <python:unicode>` text type).  For Unicode Sandwich we know that at the border of our code and the outside world (for example, file and network IO, environment variables, and some library calls) we are going to receive bytes. We need to transform these bytes into text and use that throughout the internal portions of our code.  When we have to send those strings back out to the outside world we first convert the text back into bytes. To visualize this, imagine a 'sandwich' consisting of a top and bottom layer of bytes, a layer of conversion between, and all text type in the center."
msgstr "最近まで、``ansible-core`` は Python 2.x をサポートし、Unicode Sandwich (Python 2 の :func:`unicode  <python:unicode>` テキストタイプに由来する名前) と呼ばれるストラテジーを使用していました。Unicode Sandwich の場合は、コードと外部の境界 (ファイルやネットワークの IO、環境変数、ライブラリーの呼び出しなど) でバイトを受信することがわかります。これらのバイトをテキストに変換し、コードの内部全体でこれを使用する必要があります。これらの文字列を外部に返す必要がある場合は、最初にテキストをバイトに変換します。これは、上下にバイトの層、その間に変換の層、その中央にあるすべてのテキストタイプからなる「サンドイッチ」を想像してください。"

#: ../../rst/dev_guide/developing_python_3.rst:87
msgid "For compatibility reasons you will see a bunch of custom functions we developed (``to_text``/``to_bytes``/``to_native``) and while Python 2 is not a concern anymore we will continue to use them as they apply for other cases that make dealing with unicode problematic."
msgstr "互換性の理由から、多くのカスタム関数(``to_text``/``to_bytes``/``to_native``) が開発されました。Python 2 に関する懸念はなくなったため、Unicode の処理が問題になるような別のケースに適用されるため、今後も引き続きこれを使用します。"

#: ../../rst/dev_guide/developing_python_3.rst:91
msgid "While we will not be using it most of it anymore, the documentation below is still useful for those developing modules that still need to support both Python 2 and 3 simultaneouslly."
msgstr "ほとんど使用しなくなりますが、以下のドキュメントは Python 2 と 3 の両方を同時にサポートする必要があるモジュールを開発している場合に役立ちます。"

#: ../../rst/dev_guide/developing_python_3.rst:95
msgid "Unicode Sandwich common borders: places to convert bytes to text in controller code"
msgstr "Unicode Sandwich の共通の境界: コントローラーコードのテキストにバイトを変換する場所"

#: ../../rst/dev_guide/developing_python_3.rst:97
msgid "This is a partial list of places where we have to convert to and from bytes when using the Unicode Sandwich string strategy. It's not exhaustive but it gives you an idea of where to watch for problems."
msgstr "これは、Unicode Sandwich 文字列ストラテジーの使用時に、バイトへ、またはバイトから変換する場所の部分的なリストです。網羅的ではありませんが、問題を監視する場所がわかります。"

#: ../../rst/dev_guide/developing_python_3.rst:102
msgid "Reading and writing to files"
msgstr "ファイルの読み取りおよび書き込み"

#: ../../rst/dev_guide/developing_python_3.rst:104
msgid "In Python 2, reading from files yields bytes.  In Python 3, it can yield text. To make code that's portable to both we don't make use of Python 3's ability to yield text but instead do the conversion explicitly ourselves. For example:"
msgstr "Python 2 では、ファイルから読み取るとバイトが生成されます。Python 3 では、テキストを生成できます。両方に移植可能なコードを作成するために、Python 3 のテキスト生成機能を利用せず、代わりに自身で明示的に変換を行います。以下に例を示します。"

#: ../../rst/dev_guide/developing_python_3.rst:122
msgid "Much of Ansible assumes that all encoded text is UTF-8.  At some point, if there is demand for other encodings we may change that, but for now it is safe to assume that bytes are UTF-8."
msgstr "Ansible の多くは、エンコードされたテキストがすべて UTF-8 であることを前提としています。将来変更することがあるかもしれませんが、現時点では、バイトが UTF-8 であると考えて問題ありません。"

#: ../../rst/dev_guide/developing_python_3.rst:126
msgid "Writing to files is the opposite process:"
msgstr "ファイルへの書き込みは、その逆の処理です。"

#: ../../rst/dev_guide/developing_python_3.rst:135
msgid "Note that we don't have to catch :exc:`UnicodeError` here because we're transforming to UTF-8 and all text strings in Python can be transformed back to UTF-8."
msgstr "UTF-8 に変換していて、Python のテスト文字列がすべて UTF-8 に戻されるため、ここで :exc:`UnicodeError` を取得する必要がないことに注意してください。"

#: ../../rst/dev_guide/developing_python_3.rst:140
msgid "Filesystem interaction"
msgstr "ファイルシステムの相互作用"

#: ../../rst/dev_guide/developing_python_3.rst:142
msgid "Dealing with filenames often involves dropping back to bytes because on UNIX-like systems filenames are bytes.  On Python 2, if we pass a text string to these functions, the text string will be converted to a byte string inside of the function and a traceback will occur if non-ASCII characters are present.  In Python 3, a traceback will only occur if the text string can't be decoded in the current locale, but it's still good to be explicit and have code which works on both versions:"
msgstr "UNIX 系システムではファイル名はバイトであるため、ファイル名を扱う際にはしばしばバイトに戻すことになります。Python 2 では、これらの関数にテキスト文字列を渡すと、テキスト文字列は関数内でバイト文字列に変換され、非 ASCII 文字が存在する場合にはトレースバックが発生します。Python 3 では、トレースバックはテキスト文字列が現在のロケールでデコードできない場合にのみ発生しますが、明示的に両方のバージョンで動作するコードを用意しておくことが推奨されます。"

#: ../../rst/dev_guide/developing_python_3.rst:163
msgid "When you are only manipulating a filename as a string without talking to the filesystem (or a C library which talks to the filesystem) you can often get away without converting to bytes:"
msgstr "ファイルシステム (またはファイルシステムと通信する C ライブラリー) と通信せずにファイル名を文字列として操作するだけの場合は、バイトに変換する必要がないことがよくあります。"

#: ../../rst/dev_guide/developing_python_3.rst:174
msgid "On the other hand, if the code needs to manipulate the filename and also talk to the filesystem, it can be more convenient to transform to bytes right away and manipulate in bytes."
msgstr "一方、コードがファイル名を操作し、ファイルシステムとやりとりする場合は、すぐにバイトバイトに変換して題と単位で操作する方が便利です。"

#: ../../rst/dev_guide/developing_python_3.rst:178
msgid "Make sure all variables passed to a function are the same type. If you're working with something like :func:`python3:os.path.join` which takes multiple strings and uses them in combination, you need to make sure that all the types are the same (either all bytes or all text).  Mixing bytes and text will cause tracebacks."
msgstr "関数に渡されるすべての変数が同じタイプであることを確認します。:func:`python3:os.path.join` のように、複数の文字列を取得し、これらの変数を組み合わせて使用する場合は、すべてのタイプが同じ (すべてのバイトまたはすべてのテキストのいずれか) になるようにする必要があります。バイトとテキストを混在させると、トレースバックが発生します。"

#: ../../rst/dev_guide/developing_python_3.rst:185
msgid "Interacting with other programs"
msgstr "他のプログラムとの相互作用"

#: ../../rst/dev_guide/developing_python_3.rst:187
msgid "Interacting with other programs goes through the operating system and C libraries and operates on things that the UNIX kernel defines.  These interfaces are all byte-oriented so the Python interface is byte oriented as well.  On both Python 2 and Python 3, byte strings should be given to Python's subprocess library and byte strings should be expected back from it."
msgstr "他のプログラムとの対話は、オペレーティングシステムと C ライブラリーを経由して、UNIX カーネルが定義するものを操作します。これらのインターフェースはすべてバイト指向であるため、Python インターフェースもバイト指向です。Python 2 と Python3 の両方で、バイト文字列は Python のサブプロセスライブラリーに渡され、バイト文字列はそこから返されることが期待されます。"

#: ../../rst/dev_guide/developing_python_3.rst:193
msgid "One of the main places in Ansible's controller code that we interact with other programs is the connection plugins' ``exec_command`` methods.  These methods transform any text strings they receive in the command (and arguments to the command) to execute into bytes and return stdout and stderr as byte strings Higher level functions (like action plugins' ``_low_level_execute_command``) transform the output into text strings."
msgstr "Ansible のコントローラーコードで他のプログラムとやり取りする主な場所の 1 つは、connection プラグインの ``exec_command`` メソッドです。これらのメソッドは、コマンドで受け取ったテキスト文字列 (およびコマンドへの引数) をバイトに変換し、stdout と stderr をバイト文字列として返します。(アクションプラグインの ``_low_level_execute_command`` のように) 高レベルの関数出力をテキスト文字列に変換します。"

#: ../../rst/dev_guide/developing_python_3.rst:203
msgid "Module string strategy: Native String"
msgstr "モジュール文字列ストラテジー: ネイティブ文字列"

#: ../../rst/dev_guide/developing_python_3.rst:205
msgid "In modules we use a strategy known as Native Strings. This makes things easier on the community members who maintain so many of Ansible's modules, by not breaking backwards compatibility by mandating that all strings inside of modules are text and converting between text and bytes at the borders."
msgstr "モジュールでは、ネイティブ文字列と呼ばれるストラテジーを採用しています。これにより、Ansible の多くのモジュールを保守しているコミュニティーメンバーは、モジュール内のすべての文字列がテキストであることを義務付けたり、境界でテキストとバイトの間を変換したりすることで、後方互換性を壊さないようにしています。"

#: ../../rst/dev_guide/developing_python_3.rst:211
msgid "Native strings refer to the type that Python uses when you specify a bare string literal:"
msgstr "ネイティブ文字列は、裸の文字列リテラルを指定するときに Python が使用するタイプを参照します。"

#: ../../rst/dev_guide/developing_python_3.rst:218
msgid "In Python 2, these are byte strings. In Python 3 these are text strings. Modules should be coded to expect bytes on Python 2 and text on Python 3."
msgstr "Python 2 では、これらはバイト文字列です。Python 3 では、これらはテキスト文字列です。Python 2 ではバイト、および Python 3 ではテキストを期待するようにコード化されている必要があります。"

#: ../../rst/dev_guide/developing_python_3.rst:224
msgid "Module_utils string strategy: hybrid"
msgstr "Module_utils 文字列ストラテジー: ハイブリッド"

#: ../../rst/dev_guide/developing_python_3.rst:226
msgid "In ``module_utils`` code we use a hybrid string strategy. Although Ansible's ``module_utils`` code is largely like module code, some pieces of it are used by the controller as well. So it needs to be compatible with modules and with the controller's assumptions, particularly the string strategy. The module_utils code attempts to accept native strings as input to its functions and emit native strings as their output."
msgstr "``module_utils`` コードでは、ハイブリッドな文字列ストラテジーを採用します。Ansible の ``module_utils`` コードは、大部分がモジュールコードのようなものですが、その一部はコントローラーでも使用されます。そのため、モジュールやコントローラの前提条件との互換性、特に文字列ストラテジーとの互換性が必要になります。module_utils コードは、その関数への入力としてネイティブ文字列を受け入れ、その出力としてネイティブ文字列を出力しようとします。"

#: ../../rst/dev_guide/developing_python_3.rst:233
msgid "In ``module_utils`` code:"
msgstr "``module_utils`` コードの場合:"

#: ../../rst/dev_guide/developing_python_3.rst:235
msgid "Functions **must** accept string parameters as either text strings or byte strings."
msgstr "関数は、文字列パラメーターをテキスト文字列またはバイト文字列のいずれかで使用できるようにする **必要があります**。"

#: ../../rst/dev_guide/developing_python_3.rst:236
msgid "Functions may return either the same type of string as they were given or the native string type for the Python version they are run on."
msgstr "関数は、提供された文字列と同じタイプの文字列を返すか、実行している Python のバージョンに合わせたネイティブの文字列型を返すことができます。"

#: ../../rst/dev_guide/developing_python_3.rst:237
msgid "Functions that return strings **must** document whether they return strings of the same type as they were given or native strings."
msgstr "文字列を返す関数は、指定の文字列と同じ型の文字列を返すのか、ネイティブの文字列を返すのかを文書化する **必要があります**。"

#: ../../rst/dev_guide/developing_python_3.rst:239
msgid "Module-utils functions are therefore often very defensive in nature. They convert their string parameters into text (using ``ansible.module_utils.common.text.converters.to_text``) at the beginning of the function, do their work, and then convert the return values into the native string type (using ``ansible.module_utils.common.text.converters.to_native``) or back to the string type that their parameters received."
msgstr "したがって、module_utils 関数は、本質的に非常に防御的であることがよくあります。この関数は、関数の先頭で (``ansible.module_utils.common.text.converters.to_text`` を使用して) 文字列パラメーターをテキストに変換し、作業を行い、(``ansible.module_utils.common.text.converters.to_native`` を使用して) 戻り値をネイティブの文字列型に変換します。または、パラメーターが受け取った文字列型に戻ります。"

#: ../../rst/dev_guide/developing_python_3.rst:246
msgid "Tips, tricks, and idioms for Python 2/Python 3 compatibility"
msgstr "Python 2/Python 3 互換のためのヒント、トリック、およびイディオム"

#: ../../rst/dev_guide/developing_python_3.rst:249
msgid "Use forward-compatibility boilerplate"
msgstr "前方互換性のある boilerplate の使用"

#: ../../rst/dev_guide/developing_python_3.rst:251
msgid "Use the following boilerplate code at the top of all python files to make certain constructs act the same way on Python 2 and Python 3:"
msgstr "Python 2 と Python 3 で特定の構成要素が同じように動作するようにするために、すべての python ファイルの先頭に以下の boilerplate コードを使用してください。"

#: ../../rst/dev_guide/developing_python_3.rst:260
msgid "``__metaclass__ = type`` makes all classes defined in the file into new-style classes without explicitly inheriting from :class:`object <python3:object>`."
msgstr "``__metaclass__ = type`` は、ファイルで定義されているすべてのクラスを :class:`object <python3:object>` から明示的に継承することなく、新しいスタイルのクラスにします。"

#: ../../rst/dev_guide/developing_python_3.rst:263
msgid "The ``__future__`` imports do the following:"
msgstr "``__future__`` のインポートは以下を行います。"

#: ../../rst/dev_guide/developing_python_3.rst
#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:16
msgid "absolute_import"
msgstr "absolute_import"

#: ../../rst/dev_guide/developing_python_3.rst:265
msgid "Makes imports look in :data:`sys.path <python3:sys.path>` for the modules being imported, skipping the directory in which the module doing the importing lives.  If the code wants to use the directory in which the module doing the importing, there's a new dot notation to do so."
msgstr "インポートは、インポートされるモジュールの :data:`sys.path <python3:sys.path>` を検索し、インポートを行うモジュールが存在するディレクトリーをスキップします。インポートを行うモジュールが存在するディレクトリーをコードが使用したい場合は、新しいドット表記があります。"

#: ../../rst/dev_guide/developing_python_3.rst
#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:31
msgid "division"
msgstr "division"

#: ../../rst/dev_guide/developing_python_3.rst:269
msgid "Makes division of integers always return a float.  If you need to find the quotient use ``x // y`` instead of ``x / y``."
msgstr "整数の除算が常に浮動小数点を返すようになります。商を見つける必要がある場合は、``x / y`` の代わりに ``x // y`` を使用してください。"

#: ../../rst/dev_guide/developing_python_3.rst
#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:43
msgid "print_function"
msgstr "print_function"

#: ../../rst/dev_guide/developing_python_3.rst:271
msgid "Changes :func:`print <python3:print>` from a keyword into a function."
msgstr "キーワードから関数への :func:`print <python3:print>` の変更"

#: ../../rst/dev_guide/developing_python_3.rst:274
msgid "`PEP 0328: Absolute Imports <https://www.python.org/dev/peps/pep-0328/#guido-s-decision>`_"
msgstr "`PEP 0328: Absolute Imports <https://www.python.org/dev/peps/pep-0328/#guido-s-decision>`_"

#: ../../rst/dev_guide/developing_python_3.rst:275
msgid "`PEP 0238: Division <https://www.python.org/dev/peps/pep-0238>`_"
msgstr "`PEP 0238: Division <https://www.python.org/dev/peps/pep-0238>`_"

#: ../../rst/dev_guide/developing_python_3.rst:276
msgid "`PEP 3105: Print function <https://www.python.org/dev/peps/pep-3105>`_"
msgstr "`PEP 3105: Print function <https://www.python.org/dev/peps/pep-3105>`_"

#: ../../rst/dev_guide/developing_python_3.rst:279
msgid "Prefix byte strings with ``b_``"
msgstr "バイト文字列のプレフィックス: ``b_``"

#: ../../rst/dev_guide/developing_python_3.rst:281
msgid "Since mixing text and bytes types leads to tracebacks we want to be clear about what variables hold text and what variables hold bytes.  We do this by prefixing any variable holding bytes with ``b_``.  For instance:"
msgstr "テキスト型とバイト型が混在するとトレースバックが発生するため、どの変数がテキストを保持していて、どの変数がバイトを保持しているかを明確にします。これは、バイトを保持する変数には、``b_`` をプレフィックスとして使用します。以下に例を示します。"

#: ../../rst/dev_guide/developing_python_3.rst:292
msgid "We do not prefix the text strings instead because we only operate on byte strings at the borders, so there are fewer variables that need bytes than text."
msgstr "代わりに、ボーダーのバイト文字列でのみ動作するためテキスト文字列はプレフィックスとして付けられません。したがって、テキスト文字列の前にバイト値が必要な変数が少なくなります。"

#: ../../rst/dev_guide/developing_python_3.rst:297
msgid "Import Ansible's bundled Python ``six`` library"
msgstr "Ansible のバンドルされた Python ``six`` ライブラリーをインポート"

#: ../../rst/dev_guide/developing_python_3.rst:299
msgid "The third-party Python `six <https://pypi.org/project/six/>`_ library exists to help projects create code that runs on both Python 2 and Python 3.  Ansible includes a version of the library in module_utils so that other modules can use it without requiring that it is installed on the remote system.  To make use of it, import it like this:"
msgstr "サードパーティーの Python `six <https://pypi.org/project/six/>`_ ライブラリーは、プロジェクトが Python 2 および Python 3 の両方で実行するコードを作成するのに役立ちます。Ansible には、module_utils にライブラリーのバージョンが含まれ、他のモジュールがリモートシステムにインストールされなくても使用可能となるようになっています。これを使用して、以下のようにインポートしてください。"

#: ../../rst/dev_guide/developing_python_3.rst:309
msgid "Ansible can also use a system copy of six"
msgstr "Ansible は、six のシステムコピーを使用することもできます。"

#: ../../rst/dev_guide/developing_python_3.rst:311
msgid "Ansible will use a system copy of six if the system copy is a later version than the one Ansible bundles."
msgstr "Ansible は、システムコピーが、Ansible がバンドルしているものよりも後のバージョンのものであれば、six のシステムコピーを使用します。"

#: ../../rst/dev_guide/developing_python_3.rst:315
msgid "Handle exceptions with ``as``"
msgstr "``as`` で例外を処理します。"

#: ../../rst/dev_guide/developing_python_3.rst:317
msgid "In order for code to function on Python 2.6+ and Python 3, use the new exception-catching syntax which uses the ``as`` keyword:"
msgstr "Python 2.6 以降および Python 3 でコードが機能するには、``as`` キーワードを使用する新しい例外キャッチ構文を使用してください。"

#: ../../rst/dev_guide/developing_python_3.rst:327
msgid "Do **not** use the following syntax as it will fail on every version of Python 3:"
msgstr "以下の構文は、Python 3 のすべてのバージョンで失敗するため、**使用しないでください**。"

#: ../../rst/dev_guide/developing_python_3.rst:338
msgid "Update octal numbers"
msgstr "8 進数の更新"

#: ../../rst/dev_guide/developing_python_3.rst:340
msgid "In Python 2.x, octal literals could be specified as ``0755``.  In Python 3, octals must be specified as ``0o755``."
msgstr "Python 2.x では、8 進数リテラルは ``0755`` と指定できました。Python 3 では、8 進数は ``0o755`` と指定しなければなりません。"

#: ../../rst/dev_guide/developing_python_3.rst:344
msgid "String formatting for controller code"
msgstr "コントローラーコードの文字列形式"

#: ../../rst/dev_guide/developing_python_3.rst:347
msgid "Use ``str.format()`` for Python 2.6 compatibility"
msgstr "Python 2.6 の互換性のために ``str.format()`` の使用"

#: ../../rst/dev_guide/developing_python_3.rst:349
msgid "Starting in Python 2.6, strings gained a method called ``format()`` to put strings together.  However, one commonly used feature of ``format()`` wasn't added until Python 2.7, so you need to remember not to use it in Ansible code:"
msgstr "Python 2.6 以降、文字列には、文字列をまとめる ``format()`` という名前のメソッドが追加されました。ただし、``format()`` に一般的に使用される機能の 1 つは Python 2.7 まで追加されなかったため、Ansible コードで使用しないように注意する必要があります。"

#: ../../rst/dev_guide/developing_python_3.rst:361
msgid "Both of the format strings above map positional arguments of the ``format()`` method into the string.  However, the first version doesn't work in Python 2.6.  Always remember to put numbers into the placeholders so the code is compatible with Python 2.6."
msgstr "上記の両方の形式文字列では、``format()`` メソッドの位置引数を文字列にマッピングしますが、最初のバージョンは Python 2.6 では動作しません。常に数字をプレースホルダーに置き、コードが Python 2.6 と互換性を持つようにします。"

#: ../../rst/dev_guide/developing_python_3.rst:367
msgid "Python documentation on format strings:"
msgstr "フォーマット文字列に関するPythonのドキュメント："

#: ../../rst/dev_guide/developing_python_3.rst:369
msgid "`format strings in 2.6 <https://docs.python.org/2.6/library/string.html#formatstrings>`_"
msgstr "`format strings in 2.6 <https://docs.python.org/2.6/library/string.html#formatstrings>`_"

#: ../../rst/dev_guide/developing_python_3.rst:370
msgid "`format strings in 3.x <https://docs.python.org/3/library/string.html#formatstrings>`_"
msgstr "`format strings in 3.x <https://docs.python.org/3/library/string.html#formatstrings>`_"

#: ../../rst/dev_guide/developing_python_3.rst:373
msgid "Use percent format with byte strings"
msgstr "バイト文字列でのパーセント書式の使用"

#: ../../rst/dev_guide/developing_python_3.rst:375
msgid "In Python 3.x, byte strings do not have a ``format()`` method.  However, it does have support for the older, percent-formatting."
msgstr "Python 3.x では、バイト文字列に ``format()`` メソッドがありませんが、以前のパーセント形式をサポートします。"

#: ../../rst/dev_guide/developing_python_3.rst:382
msgid "Percent formatting added in Python 3.5"
msgstr "Python 3.5 に追加されたパーセント書式"

#: ../../rst/dev_guide/developing_python_3.rst:384
msgid "Percent formatting of byte strings was added back into Python 3 in 3.5. This isn't a problem for us because Python 3.5 is our minimum version. However, if you happen to be testing Ansible code with Python 3.4 or earlier, you will find that the byte string formatting here won't work. Upgrade to Python 3.5 to test."
msgstr "Python 3 では、Python 3.5 に、バイト文字列のパーセント書式が追加されました。Python 3.5 は最小バージョンであるため、これは問題ではありません。ただし、Python 3.4 以前のバージョンで Ansible のコードをテストしている場合は、ここでのバイト文字列の書式設定が適切に処理されないことがあります。その場合は、Python 3.5 にアップグレードしてテストしてください。"

#: ../../rst/dev_guide/developing_python_3.rst:391
msgid "Python documentation on `percent formatting <https://docs.python.org/3/library/stdtypes.html#string-formatting>`_"
msgstr "`percent formatting <https://docs.python.org/3/library/stdtypes.html#string-formatting>`_ に関する Python ドキュメント"

#: ../../rst/dev_guide/developing_rebasing.rst:5
msgid "Rebasing a pull request"
msgstr "プル要求のリベース"

#: ../../rst/dev_guide/developing_rebasing.rst:7
msgid "You may find that your pull request (PR) is out-of-date and needs to be rebased. This can happen for several reasons:"
msgstr "プル要求 (PR) が古いため、リベースが必要になる場合があります。これにはいくつかの理由が考えられます。"

#: ../../rst/dev_guide/developing_rebasing.rst:9
msgid "Files modified in your PR are in conflict with changes which have already been merged."
msgstr "発行する PR で変更されたファイルは、すでにマージされている変更と競合しています。"

#: ../../rst/dev_guide/developing_rebasing.rst:10
msgid "Your PR is old enough that significant changes to automated test infrastructure have occurred."
msgstr "発行する PR は、自動化されたテストインフラストラクチャーに大幅な変更が加えられるほど古いものです。"

#: ../../rst/dev_guide/developing_rebasing.rst:12
msgid "Rebasing the branch used to create your PR will resolve both of these issues."
msgstr "PR を作成するのに使用するブランチを再設定すると、この両方の問題が解決されます。"

#: ../../rst/dev_guide/developing_rebasing.rst:15
msgid "Configuring your remotes"
msgstr "リモートの設定"

#: ../../rst/dev_guide/developing_rebasing.rst:17
msgid "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:"
msgstr "PR をリベースする前に、適切なリモートが設定されていることを確認する必要があります。この手順は、コレクションリポジトリーを含む GitHub のすべてのリポジトリーに適用されます。他のプラットフォーム (bitbucket や gitlab) でも同様の原則とコマンドが適用されますが、構文が異なる場合があります。ここでは、ansible/ansible のリポジトリーを例に挙げています。他のリポジトリーでは、ブランチ名が異なる場合があります。通常の方法でフォークをクローンしたと仮定すると、``origin`` のリモートは操作したユーザーのフォークを指すことになります。"

#: ../../rst/dev_guide/developing_rebasing.rst:25
msgid "However, you also need to add a remote which points to the upstream repository:"
msgstr "ただし、アップストリームのリポジトリーを参照するリモートを追加する必要もあります。"

#: ../../rst/dev_guide/developing_rebasing.rst:31
msgid "Which should leave you with the following remotes:"
msgstr "次のリモートを残す必要があります。"

#: ../../rst/dev_guide/developing_rebasing.rst:41
msgid "Checking the status of your branch should show your fork is up-to-date with the ``origin`` remote:"
msgstr "ブランチのステータスを確認すると、``origin`` のリモートのフォークが最新の状態であることを理解できます。"

#: ../../rst/dev_guide/developing_rebasing.rst:51
msgid "Rebasing your branch"
msgstr "ブランチのリベース"

#: ../../rst/dev_guide/developing_rebasing.rst:53
msgid "Once you have an ``upstream`` remote configured, you can rebase the branch for your PR:"
msgstr "``upstream`` のリモートを設定したら、PR のブランチをリベースできます。"

#: ../../rst/dev_guide/developing_rebasing.rst:59
msgid "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."
msgstr "これにより、アップストリームの ``devel`` ブランチで変更したブランチに変更が再生されます。マージの競合が発生した場合は、続行する前に解決するように求められます。"

#: ../../rst/dev_guide/developing_rebasing.rst:62
msgid "After you rebase, the status of your branch changes:"
msgstr "リベース後に、ブランチのステータスが変更になります。"

#: ../../rst/dev_guide/developing_rebasing.rst:73
msgid "Don't worry, this is normal after a rebase. You should ignore the ``git status`` instructions to use ``git pull``. We'll cover what to do next in the following section."
msgstr "リベースの後、これは通常通りとなります。``git pull`` を使用する ``git status`` 命令は無視する必要があります。次のセクションでは、次に何をするかについて説明します。"

#: ../../rst/dev_guide/developing_rebasing.rst:76
msgid "Updating your pull request"
msgstr "プル要求の更新"

#: ../../rst/dev_guide/developing_rebasing.rst:78
msgid "Now that you've rebased your branch, you need to push your changes to GitHub to update your PR."
msgstr "ブランチをリベースしたら、変更を GitHub にプッシュして、PR を更新する必要があります。"

#: ../../rst/dev_guide/developing_rebasing.rst:80
msgid "Since rebasing re-writes git history, you will need to use a force push:"
msgstr "リベースは、git 履歴を再書き込みするため、強制的にプッシュする必要があります。"

#: ../../rst/dev_guide/developing_rebasing.rst:86
msgid "Your PR on GitHub has now been updated. This will automatically trigger testing of your changes. You should check in on the status of your PR after tests have completed to see if further changes are required."
msgstr "GitHub の PR が更新されました。これにより、変更のテストが自動的に発生します。テスト完了後に PR のステータスを確認し、さらなる変更が必要であるかどうかを確認する必要があります。"

#: ../../rst/dev_guide/developing_rebasing.rst:90
msgid "Getting help rebasing"
msgstr "リベースのヘルプ"

#: ../../rst/dev_guide/developing_rebasing.rst:92
msgid "For help with rebasing your PR, or other development related questions, join us on the #ansible-devel chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat <https://libera.chat/>`_)."
msgstr "PR またはその他の開発関連の質問を再設定する際には、チャットチャンネル #ansible-devel に参加します（ansible.imでMatrixを使用、または`irc.libera.chat <https://libera.chat/>`でIRCを使用）。"

#: ../../rst/dev_guide/developing_rebasing.rst:96
msgid ":ref:`community_development_process`"
msgstr ":ref:`community_development_process`"

#: ../../rst/dev_guide/developing_rebasing.rst:97
msgid "Information on roadmaps, opening PRs, Ansibullbot, and more"
msgstr "ロードマップ、オープン PRS、Ansibullbot などに関する情報"

#: ../../rst/dev_guide/migrating_roles.rst:6
msgid "Migrating Roles to Roles in Collections on Galaxy"
msgstr "ロールの、Galaxy のコレクション内のロールへの移行"

#: ../../rst/dev_guide/migrating_roles.rst:8
msgid "You can migrate any existing standalone role into a collection and host the collection on Galaxy. With Ansible collections, you can distribute many roles in a single cohesive unit of re-usable automation. Inside a collection, you can share custom plugins across all roles in the collection instead of duplicating them in each role's :file:`library/`` directory."
msgstr "既存のスタンドアロンロールをコレクションに移行し、コレクションを Galaxy 上でホストすることができます。Ansible コレクションを使用すると、再利用可能な自動化の 1 つのまとまったユニットで多くのロールを配布できます。コレクションの中では、カスタムプラグインを各ロールの :file:`library/`` ディレクトリーに複製するのではなく、コレクション内のすべてのロールで共有することができます。"

#: ../../rst/dev_guide/migrating_roles.rst:10
msgid "You must migrate roles to collections if you want to distribute them as certified Ansible content."
msgstr "ロールを認定済みの Ansible コンテンツとして配布する場合は、ロールをコレクションに移行する必要があります。"

#: ../../rst/dev_guide/migrating_roles.rst:14
msgid "If you want to import your collection to Galaxy, you need a `Galaxy namespace <https://galaxy.ansible.com/docs/contributing/namespaces.html>`_."
msgstr "コレクションを Galaxy にインポートする場合は、`Galaxy 名前空間 <https://galaxy.ansible.com/docs/contributing/namespaces.html>`_ が必要です。"

#: ../../rst/dev_guide/migrating_roles.rst:16
msgid "See :ref:`developing_collections` for details on collections."
msgstr "コレクションの詳細は、「:ref:`developing_collections`」を参照してください。"

#: ../../rst/dev_guide/migrating_roles.rst:24
msgid "Comparing standalone roles to collection roles"
msgstr "スタンドアロンロールとコレクションロールの比較"

#: ../../rst/dev_guide/migrating_roles.rst:26
msgid ":ref:`Standalone roles <playbooks_reuse_roles>` have the following directory structure:"
msgstr ":ref:`Standalone roles <playbooks_reuse_roles>` に、以下のディレクトリー構造があります。"

#: ../../rst/dev_guide/migrating_roles.rst:45
msgid "The highlighted directories above will change when you migrate to a collection-based role. The collection directory structure includes a :file:`roles/` directory:"
msgstr "上記の強調表示されたディレクトリーは、コレクションベースのロールへの移行時に変化します。コレクションディレクトリー構造には、:file:`roles/` ディレクトリーが含まれます。"

#: ../../rst/dev_guide/migrating_roles.rst:70
msgid "You will need to use the Fully Qualified Collection Name (FQCN) to use the roles and plugins when you migrate your role into a collection. The FQCN is the combination of the collection ``namespace``, collection ``name``, and the content item you are referring to."
msgstr "ロールをコレクションに移行するときにロールおよびプラグインを使用するために、完全修飾コレクション名 (FQCN) を使用する必要があります。FQCN は、コレクション ``namespace``、コレクション ``name``、および参照するコンテンツアイテムの組み合わせになります。"

#: ../../rst/dev_guide/migrating_roles.rst:72
msgid "So for example, in the above collection, the FQCN to access  ``role1`` would be:"
msgstr "たとえば、上記のコレクションでは、``role1`` にアクセスする FQCN は以下のようになります。"

#: ../../rst/dev_guide/migrating_roles.rst:79
msgid "A collection can contain one or more roles in the :file:`roles/` directory and these are almost identical to standalone roles, except you need to move plugins out of the individual roles, and use the :abbr:`FQCN (Fully Qualified Collection Name)` in some places, as detailed in the next section."
msgstr "コレクションには、:file:`roles/` ディレクトリーに 1 つまたは複数のロールを含めることができ、これらのロールはスタンドアロンロールとほぼ同じです。ただし、個別のロールからプラグインを外に移動し、一部では :abbr:`FQCN (Fully Qualified Collection Name)` を使用します。これは、次のセクションで詳細に説明します。"

#: ../../rst/dev_guide/migrating_roles.rst:83
msgid "In standalone roles, some of the plugin directories referenced their plugin types in the plural sense; this is not the case in collections."
msgstr "スタンドアロンロールでは、プラグインディレクトリーの一部が複数の意味でプラグインタイプを参照していました。コレクションではこのようになりません。"

#: ../../rst/dev_guide/migrating_roles.rst:88
msgid "Migrating a role to a collection"
msgstr "ロールのコレクションへの移行"

#: ../../rst/dev_guide/migrating_roles.rst:90
msgid "To migrate from a standalone role that contains no plugins to a collection role:"
msgstr "プラグインが含まれないスタンドアロンロールからコレクションロールに移行するには、以下を行います。"

#: ../../rst/dev_guide/migrating_roles.rst:92
msgid "Create a local :file:`ansible_collections` directory and ``cd`` to this new directory."
msgstr "ローカルの :file:`ansible_collections` ディレクトリーを作成し、この新しいディレクトリーに ``cd`` を作成します。"

#: ../../rst/dev_guide/migrating_roles.rst:94
#: ../../rst/dev_guide/migrating_roles.rst:122
msgid "Create a collection. If you want to import this collection to Ansible Galaxy, you need a `Galaxy namespace <https://galaxy.ansible.com/docs/contributing/namespaces.html>`_."
msgstr "コレクションを作成します。このコレクションを Ansible Galaxy にインポートする場合は、`Galaxy 名前空間 <https://galaxy.ansible.com/docs/contributing/namespaces.html>`_ が必要です。"

#: ../../rst/dev_guide/migrating_roles.rst:100
#: ../../rst/dev_guide/migrating_roles.rst:128
msgid "This creates the collection directory structure."
msgstr "これにより、コレクションディレクトリー構造が作成されます。"

#: ../../rst/dev_guide/migrating_roles.rst:102
#: ../../rst/dev_guide/migrating_roles.rst:130
msgid "Copy the standalone role directory into the :file:`roles/` subdirectory of the collection. Roles in collections cannot have hyphens in the role name. Rename any such roles to use underscores instead."
msgstr "スタンドアロンのロールディレクトリーをコレクションの :file:`roles/` サブディレクトリーにコピーします。コレクション内のロールにはロール名にハイフンを設定できません。このようなロールは名前を変更し、代わりにアンダースコアを使用するようにします。"

#: ../../rst/dev_guide/migrating_roles.rst:109
#: ../../rst/dev_guide/migrating_roles.rst:146
msgid "Update ``galaxy.yml`` to include any role dependencies."
msgstr "``galaxy.yml`` を更新して、ロールの依存関係を追加します。"

#: ../../rst/dev_guide/migrating_roles.rst:111
#: ../../rst/dev_guide/migrating_roles.rst:148
msgid "Update the collection README.md file to add links to any role README.md files."
msgstr "コレクション README.md ファイルを更新して、ロールの README.md ファイルへのリンクを追加します。"

#: ../../rst/dev_guide/migrating_roles.rst:116
msgid "Migrating a role that contains plugins to a collection"
msgstr "プラグインが含まれるロールからコレクションへの移行"

#: ../../rst/dev_guide/migrating_roles.rst:118
msgid "To migrate from a standalone role that has plugins to a collection role:"
msgstr "プラグインが含まれないスタンドアロンロールからコレクションロールに移行するには、以下を行います。"

#: ../../rst/dev_guide/migrating_roles.rst:120
msgid "Create a local :file:`ansible_collections directory` and ``cd`` to this new directory."
msgstr "ローカルの :file:`ansible_collections directory` および ``cd`` をこの新しいディレクトリーに作成します。"

#: ../../rst/dev_guide/migrating_roles.rst:138
msgid "Move any modules to the :file:`plugins/modules/` directory."
msgstr "モジュールを :file:`plugins/modules/` ディレクトリーに移動します。"

#: ../../rst/dev_guide/migrating_roles.rst:144
msgid "Move any other plugins to the appropriate :file:`plugins/PLUGINTYPE/` directory.  See :ref:`migrating_plugins_collection` for additional steps that may be required."
msgstr "その他のプラグインを適切な :file:`plugins/PLUGINTYPE/` ディレクトリーに移動します。必要となる可能性のある追加手順については、「:ref:`migrating_plugins_collection`」を参照してください。"

#: ../../rst/dev_guide/migrating_roles.rst:150
msgid "Change any references to the role to use the :abbr:`FQCN (Fully Qualified Collection Name)`."
msgstr ":abbr:`FQCN (Fully Qualified Collection Name)` を使用するように、ロールへの参照を変更します。"

#: ../../rst/dev_guide/migrating_roles.rst:163
msgid "You can alternately use the ``collections`` keyword to simplify this:"
msgstr "別の方法では、``collections`` キーワードを使用してこれを単純化することもできます。"

#: ../../rst/dev_guide/migrating_roles.rst:181
msgid "Migrating other role plugins to a collection"
msgstr "他のロールプラグインからコレクションへの移行"

#: ../../rst/dev_guide/migrating_roles.rst:183
msgid "To migrate other role plugins to a collection:"
msgstr "その他のロールプラグインをコレクションに移行するには、以下を実行します。"

#: ../../rst/dev_guide/migrating_roles.rst:186
msgid "Move each nonmodule plugins to the appropriate :file:`plugins/PLUGINTYPE/` directory. The :file:`mynamespace/mycollection/plugins/README.md` file explains the types of plugins that the collection can contain within optionally created subdirectories."
msgstr "モジュール以外の各プラグインを適切な :file:`plugins/PLUGINTYPE/` ディレクトリーに移動します。:file:`mynamespace/mycollection/plugins/README.md` ファイルは、任意で作成されたサブディレクトリー内にコレクションが含めることができるプラグインのタイプを説明します。"

#: ../../rst/dev_guide/migrating_roles.rst:192
msgid "Update documentation to use the FQCN. Plugins that use ``doc_fragments`` need to use FQCN (for example, ``mydocfrag`` becomes ``mynamespace.mycollection.mydocfrag``)."
msgstr "FQCN を使用するようにドキュメントを更新します。``doc_fragments`` を使用するプラグインは、FQCN を使用する必要があります (たとえば、``mydocfrag`` は ``mynamespace.mycollection.mydocfrag`` になります)。"

#: ../../rst/dev_guide/migrating_roles.rst:194
msgid "Update relative imports work in collections to start with a period.  For example, :file:`./filename` and :file:`../asdfu/filestuff` works but :file:`filename` in same directory must be updated to :file:`./filename`."
msgstr "コレクション内の相対インポート作業を更新し、ピリオドで開始します。たとえば、:file:`./filename` および :file:`../asdfu/filestuff` は有効ですが、同じディレクトリー内の :file:`filename` を :file:`./filename` に更新する必要があります。"

#: ../../rst/dev_guide/migrating_roles.rst:197
msgid "If you have a custom ``module_utils`` or import from ``__init__.py``, you must also:"
msgstr "カスタムの ``module_utils`` がある、または ``__init__.py`` からインポートする場合は、以下も必要になります。"

#: ../../rst/dev_guide/migrating_roles.rst:199
msgid "Change the Python namespace for custom ``module_utils`` to use the :abbr:`FQCN (Fully Qualified Collection Name)` along with the ``ansible_collections`` convention. See :ref:`update_module_utils_role`."
msgstr "カスタム ``module_utils`` の Python 名前空間が、``ansible_collections`` 規則と共に :abbr:`FQCN (Fully Qualified Collection Name)` を使用するように変更します。「:ref:`update_module_utils_role`」を参照してください。"

#: ../../rst/dev_guide/migrating_roles.rst:201
msgid "Change how you import from ``__init__.py``. See :ref:`update_init_role`."
msgstr "``__init__.py`` からインポートする方法を変更します。「:ref:`update_init_role`」を参照してください。"

#: ../../rst/dev_guide/migrating_roles.rst:207
msgid "Updating ``module_utils``"
msgstr "``module_utils`` の更新"

#: ../../rst/dev_guide/migrating_roles.rst:209
msgid "If any of your custom modules use a custom module utility, once you migrate to a collection you cannot address the module utility in the top level ``ansible.module_utils`` Python namespace. Ansible does not merge content from collections into the Ansible internal Python namespace. Update any Python import statements that refer to custom module utilities when you migrate your custom content to collections. See :ref:`module_utils in collections <collection_module_utils>` for more details."
msgstr "カスタムモジュールのいずれかがカスタムモジュールユーティリティーを使用している場合は、コレクションに移行すると、上位レベルの ``ansible.module_utils`` Python 名前空間でモジュールユーティリティーを扱うことができません。Ansible は、コレクションのコンテンツを Ansible 内部の Python 名前空間にマージしません。カスタムコンテンツをコレクションに移行する際は、カスタムモジュールユーティリティーを参照している Python の import 文を更新してください。詳細は、「:ref:`コレクションの module_utils <collection_module_utils>`」を参照してください。"

#: ../../rst/dev_guide/migrating_roles.rst:211
msgid "When coding with ``module_utils`` in a collection, the Python import statement needs to take into account the :abbr:`FQCN (Fully Qualified Collection Name)` along with the ``ansible_collections`` convention. The resulting Python import looks similar to the following example:"
msgstr "コレクションで ``module_utils`` を使用してコーディングする場合、Python の import ステートメントは ``ansible_collections`` 規則とともに :abbr:`FQCN (Fully Qualified Collection Name)` を考慮する必要があります。作成される Python インポートは以下のようになります。"

#: ../../rst/dev_guide/migrating_roles.rst:219
msgid "You need to follow the same rules in changing paths and using namespaced names for subclassed plugins."
msgstr "パスの変更と同じルールに従い、サブクラスのプラグインに名前空間を使用した名前を使用する必要があります。"

#: ../../rst/dev_guide/migrating_roles.rst:221
msgid "The following example code snippets show a Python and a PowerShell module using both default Ansible ``module_utils`` and those provided by a collection. In this example the namespace is ``ansible_example`` and the collection is ``community``."
msgstr "以下のスニペットの例は、デフォルトの Ansible ``module_utils`` と、コレクションの両方を使用する Python および PowerShell モジュールを示しています。この例では、名前空間は ``ansible_example`` で、コレクションは ``community`` です。"

#: ../../rst/dev_guide/migrating_roles.rst:223
msgid "In the Python example the ``module_utils`` is ``helper`` and the :abbr:`FQCN (Fully Qualified Collection Name)` is ``ansible_example.community.plugins.module_utils.helper``:"
msgstr "Python の例では、``module_utils`` が ``helper`` で、:abbr:`FQCN (Fully Qualified Collection Name)` は ``ansible_example.community.plugins.module_utils.helper`` です。"

#: ../../rst/dev_guide/migrating_roles.rst:249
msgid "In the PowerShell example the ``module_utils`` is ``hyperv`` and the :abbr:`FQCN (Fully Qualified Collection Name)` is ``ansible_example.community.plugins.module_utils.hyperv``:"
msgstr "PowerShell の例では、``module_utils`` が ``hyperv`` で、:abbr:`FQCN (Fully Qualified Collection Name)` は ``ansible_example.community.plugins.module_utils.hyperv`` です。"

#: ../../rst/dev_guide/migrating_roles.rst:271
msgid "Importing from __init__.py"
msgstr "__init__.py からのインポート"

#: ../../rst/dev_guide/migrating_roles.rst:273
msgid "Because of the way that the CPython interpreter does imports, combined with the way the Ansible plugin loader works, if your custom embedded module or plugin requires importing something from an :file:`__init__.py` file, that also becomes part of your collection. You can either originate the content inside a standalone role or use the file name in the Python import statement. The following example is an :file:`__init__.py` file that is part of a callback plugin found inside a collection named ``ansible_example.community``."
msgstr "CPython インタープリターがインポートを行う方法と、Ansible プラグインローダーが動作する方法を組み合わせることで、カスタムの組み込みモジュールやプラグインが :file:`__init__.py` ファイルから何かをインポートする必要がある場合は、それもコレクションの一部になります。コンテンツをスタンドアロンのロールの内部で生成するか、Python の import 文でファイル名を使用することができます。次の例は、``ansible_example.community`` という名前のコレクションの中にある callback プラグインの一部である :file:`__init__.py` ファイルです。"

#: ../../rst/dev_guide/migrating_roles.rst:281
msgid "Example: Migrating a standalone role with plugins to a collection"
msgstr "例: プラグインを持つスタンドアロンロールをコレクションに移行"

#: ../../rst/dev_guide/migrating_roles.rst:283
msgid "In this example we have a standalone role called ``my-standalone-role.webapp`` to emulate a standalone role that contains dashes in the name (which is not valid in collections). This standalone role contains a custom module in the ``library/`` directory called ``manage_webserver``."
msgstr "この例では、``my-standalone-role.webapp`` という名前のスタンドアロンのロールがあり、名前にダッシュが含まれるスタンドアロンのロールをエミュレートします (コレクションで有効なものではありません)。このスタンドアロンロールには、``manage_webserver`` と呼ばれる ``library/`` ディレクトリーのカスタムモジュールが含まれます。"

#: ../../rst/dev_guide/migrating_roles.rst:298
msgid "Create a new collection, for example, ``acme.webserver``:"
msgstr "新規コレクションを作成します (``acme.webserver`` など)。"

#: ../../rst/dev_guide/migrating_roles.rst:311
msgid "Create the ``webapp`` role inside the collection and copy all contents from the standalone role:"
msgstr "コレクション内に ``webapp`` ロールを作成し、standalone ロールからすべてのコンテンツをコピーします。"

#: ../../rst/dev_guide/migrating_roles.rst:318
msgid "Move the ``manage_webserver`` module to its new home in ``acme/webserver/plugins/modules/``:"
msgstr "``manage_webserver`` モジュールを ``acme/webserver/plugins/modules/`` 内の新しいホームに移動します。"

#: ../../rst/dev_guide/migrating_roles.rst:326
msgid "This example changed the original source file ``manage_webserver.py`` to the destination file ``manage.py``. This is optional but the :abbr:`FQCN (Fully Qualified Collection Name)` provides the ``webserver`` context as ``acme.webserver.manage``."
msgstr "この例では、元のソースファイル ``manage_webserver.py`` を宛先ファイル ``manage.py`` に変更しました。これは任意ですが、:abbr:`FQCN (Fully Qualified Collection Name)` は、``acme.webserver.manage`` として ``webserver`` のコンテキストを提供します。"

#: ../../rst/dev_guide/migrating_roles.rst:328
msgid "Change ``manage_webserver`` to ``acme.webserver.manage`` in :file:`tasks/` files in the role ( for example, ``my-standalone-role.webapp/tasks/main.yml``) and any use of the original module name."
msgstr "ロール内の :file:`tasks/` ファイルで ``manage_webserver`` を ``acme.webserver.manage`` に変更 (``my-standalone-role.webapp/tasks/main.yml`` など) し、元のモジュール名を使用します。"

#: ../../rst/dev_guide/migrating_roles.rst:332
msgid "This name change is only required if you changed the original module name, but illustrates content referenced by :abbr:`FQCN (Fully Qualified Collection Name)` can offer context and in turn can make module and plugin names shorter. If you anticipate using these modules independent of the role, keep the original naming conventions. Users can add the  :ref:`collections keyword <collections_using_playbook>` in their playbooks. Typically roles are an abstraction layer and users won't use components of the role independently."
msgstr "この名前の変更は、元のモジュール名を変更した場合にのみ必要ですが、:abbr:`FQCN (Fully Qualified Collection Name)` で参照されるコンテンツを例示することで、コンテキストを提供し、ひいてはモジュールやプラグインの名前を短くすることができます。これらのモジュールをロールとは関係なく使用することを想定している場合は、元の命名規則を維持してください。ユーザーは、Playbook に :ref:`コレクションのキーワード <collections_using_playbook>` を追加することができます。通常、ロールは抽象レイヤーであり、ユーザーはロールのコンポーネントを個別に使用することはありません。"

#: ../../rst/dev_guide/migrating_roles.rst:336
msgid "Example: Supporting standalone roles and migrated collection roles in a downstream RPM"
msgstr "例: ダウンストリーム RPM でのスタンドアロンロールと移行されたコレクションロールのサポート"

#: ../../rst/dev_guide/migrating_roles.rst:338
msgid "A standalone role can co-exist with its collection role counterpart (for example, as part of a support lifecycle of a product). This should only be done for a transition period, but these two can exist in downstream in packages such as RPMs. For example, the RHEL system roles could coexist with an `example of a RHEL system roles collection <https://github.com/maxamillion/collection-rhel-system-roles>`_ and provide existing backwards compatibility with the downstream RPM."
msgstr "スタンドアロンのロールは、対応するコレクションロールと共存することができます (例: 製品のサポートライフサイクルの一部として)。これは移行期間のみ行うべきですが、これら 2 つは RPM などのパッケージでダウンストリームに存在することができます。たとえば、RHEL のシステムロールは `example of a RHEL system roles collection <https://github.com/maxamillion/collection-rhel-system-roles>`_ と共存し、ダウンストリーム RPM との既存の後方互換性を提供することができます。"

#: ../../rst/dev_guide/migrating_roles.rst:340
msgid "This section walks through an example creating this coexistence in a downstream RPM and requires Ansible 2.9.0 or later."
msgstr "本セクションでは、ダウンストリーム RPM でこの共存を作成し、Ansible 2.9.0 以降が必要になります。"

#: ../../rst/dev_guide/migrating_roles.rst:342
msgid "To deliver a role as both a standalone role and a collection role:"
msgstr "スタンドアロンロールとコレクションロールの両方としてロールを提供するには、以下を実行します。"

#: ../../rst/dev_guide/migrating_roles.rst:344
msgid "Place the collection in  :file:`/usr/share/ansible/collections/ansible_collections/`."
msgstr "コレクションを :file:`/usr/share/ansible/collections/ansible_collections/` に置きます。"

#: ../../rst/dev_guide/migrating_roles.rst:345
msgid "Copy the contents of the role inside the collection into a directory named after the standalone role and place the standalone role in  :file:`/usr/share/ansible/roles/`."
msgstr "コレクション内のロールの内容をスタンドアロンロールにちなんで名付けられたディレクトリーにコピーし、スタンドアロンロールを :file:`/usr/share/ansible/roles/` に置きます。"

#: ../../rst/dev_guide/migrating_roles.rst:347
msgid "All previously bundled modules and plugins used in the standalone role are now referenced by :abbr:`FQCN (Fully Qualified Collection Name)` so even though they are no longer embedded, they can be found from the collection contents.This is an example of how the content inside the collection is a unique entity and does not have to be bound to a role or otherwise. You could alternately create two separate collections: one for the modules and plugins and another for the standalone role to migrate to. The role must use the modules and plugins as :abbr:`FQCN (Fully Qualified Collection Name)`."
msgstr "スタンドアロンロールで使用されていた、以前にバンドルされていたモジュールやプラグインは、すべて :abbr:`FQCN (Fully Qualified Collection Name)` で参照されるようになりました。そのため、それらはもはや埋め込まれていないにもかかわらず、コレクションのコンテンツから見つけることができます。これは、コレクション内のコンテンツが固有のエンティティーであり、ロールなどに縛られる必要がないことを示す例です。別の方法として、2 つの独立したコレクションを作成することもできます。1 つはモジュールとプラグイン用、もう 1 つは移行先のスタンドアロンロール用です。ロールは、モジュールとプラグインを :abbr:`FQCN (Fully Qualified Collection Name)` として使用する必要があります。"

#: ../../rst/dev_guide/migrating_roles.rst:349
msgid "The following is an example RPM spec file that accomplishes this using this example content:"
msgstr "以下は、このサンプルの内容を使用してこれを実現する RPM 仕様ファイルの例です。"

#: ../../rst/dev_guide/migrating_roles.rst:414
msgid "Using ``ansible.legacy`` to access local custom modules from collections-based roles"
msgstr "``ansible.legacy`` を使用したコレクションベースのロールからローカルのカスタムモジュールへのアクセス"

#: ../../rst/dev_guide/migrating_roles.rst:416
msgid "Some roles within a collection use :ref:`local custom modules <developing_locally>` that are not part of the collection itself. If there is a conflict between the custom module short name and the collection module name, you need to specify which module your tasks call. You can update the tasks to change ``local_module_name`` to ``ansible.legacy.local_module_name`` to ensure you are using the custom module."
msgstr "コレクション内の一部のロールは、コレクション自体の一部ではない :ref:`local custom modules <developing_locally>` を使用します。カスタムモジュールの短縮名とコレクションモジュール名の間に競合がある場合は、タスクが呼び出すモジュールを指定する必要があります。タスクを更新し、``local_module_name`` を ``ansible.legacy.local_module_name`` に変更して、カスタムモジュールを使用していることを確認してください。"

#: ../../rst/dev_guide/module_lifecycle.rst:5
msgid "The lifecycle of an Ansible module or plugin"
msgstr "Ansible モジュールまたはプラグインのライフサイクル"

#: ../../rst/dev_guide/module_lifecycle.rst:7
msgid "Modules and plugins in the main Ansible repository have a defined life cycle, from the first introduction to final removal. The module and plugin lifecycle is tied to the `Ansible release cycle <release_cycle>`. A module or plugin may move through these four stages:"
msgstr "メインの Ansible リポジトリーのモジュールおよびプラグインには、最初の導入から最後の削除までライフサイクルが定義されます。モジュールおよびプラグインのライフサイクルは、`Ansible リリースサイクル <release_cycle>` に紐づけられ、モジュールまたはプラグインは、次の 4 つの段階を通過する可能性があります。"

#: ../../rst/dev_guide/module_lifecycle.rst:10
msgid "When a module or plugin is first accepted into Ansible, we consider it in tech preview and will mark it as such in the documentation."
msgstr "モジュールまたはプラグインが最初に Ansible に受け入れられると、テクノロジープレビューでそれが考慮され、そのようにマークされます。"

#: ../../rst/dev_guide/module_lifecycle.rst:12
msgid "If a module or plugin matures, the 'preview' mark in the documentation is removed. Backward compatibility for these modules and plugins is maintained but not guaranteed, which means their parameters should be maintained with stable meanings."
msgstr "モジュールまたはプラグインが成熟すると、ドキュメントの「preview」マークが削除されます。これらのモジュールおよびプラグインの後方互換性は維持されますが保証されません。これは、これらのパラメーターが安定した意味で維持されるべきことを意味します。"

#: ../../rst/dev_guide/module_lifecycle.rst:14
msgid "If a module's or plugin's target API changes radically, or if someone creates a better implementation of its functionality, we may mark it deprecated. Modules and plugins that are deprecated are still available but they are reaching the end of their life cycle. We retain deprecated modules and plugins for 4 release cycles with deprecation warnings to help users update playbooks and roles that use them."
msgstr "モジュールまたはプラグインのターゲット API が大幅に変更された場合、または誰かがその機能に対してより良い実装を作成した場合は、非推奨と表示することがあります。非推奨のモジュールまたはプラグインは引き続き利用できますが、ライフサイクルの終わりに近づいています。非推奨のモジュールまたはプラグインは 4 つのリリースサイクルの間保持され、ユーザーはそれを使用する Playbook とロールを更新できるように非推奨の警告が表示されます。"

#: ../../rst/dev_guide/module_lifecycle.rst:16
msgid "When a module or plugin has been deprecated for four release cycles, it is removed and replaced with a tombstone entry in the routing configuration. Modules and plugins that are removed are no longer shipped with Ansible. The tombstone entry helps users find alternative modules and plugins."
msgstr "4 つのリリースサイクルでモジュールまたはプラグインは非推奨となり、ルーティング設定の tombstone エントリーに置き換えられます。削除されたモジュールおよびプラグインは Ansible に同梱されなくなります。tombstone エントリーは、別のモジュールおよびプラグインを見つけることができます。"

#: ../../rst/dev_guide/module_lifecycle.rst:18
msgid "For modules and plugins in collections, the lifecycle is similar. Since ansible-base 2.10, it is no longer possible to mark modules as 'preview' or 'stable'."
msgstr "コレクションにあるモジュールおよびプラグインでは、ライフサイクルが類似しています。ansible-base 2.10 では、モジュールを「preview」または「stable」のマークを付けることができなくなります。"

#: ../../rst/dev_guide/module_lifecycle.rst:23
msgid "Deprecating modules and plugins in the Ansible main repository"
msgstr "Ansible メインリポジトリーでのモジュールおよびプラグインの非推奨化"

#: ../../rst/dev_guide/module_lifecycle.rst:25
msgid "To deprecate a module in ansible-core, you must:"
msgstr "ansible-core でモジュールを非推奨にするには、以下を行う必要があります。"

#: ../../rst/dev_guide/module_lifecycle.rst:27
msgid "Rename the file so it starts with an ``_``, for example, rename ``old_cloud.py`` to ``_old_cloud.py``. This keeps the module available and marks it as deprecated on the module index pages."
msgstr "ファイルの名前を ``_`` で始まるように変更します。たとえば、``old_cloud.py`` の名前を ``_old_cloud.py`` に変更します。これにより、モジュールが利用可能のままとなり、モジュールインデックスページで非推奨としてマークされます。"

#: ../../rst/dev_guide/module_lifecycle.rst:28
msgid "Mention the deprecation in the relevant changelog (by creating a changelog fragment with a section ``deprecated_features``)."
msgstr "(``deprecated_features`` セクションを使用して changelog フラグメントを作成することで) 関連する変更ログで非推奨となったことを説明します。"

#: ../../rst/dev_guide/module_lifecycle.rst:29
msgid "Reference the deprecation in the relevant ``porting_guide_core_x.y.rst``."
msgstr "関連する ``porting_guide_core_x.y.rst`` で非推奨化を参照します。"

#: ../../rst/dev_guide/module_lifecycle.rst:30
msgid "Add ``deprecated:`` to the documentation with the following sub-values:"
msgstr "次のサブ値を使用して、``deprecated:`` をドキュメントに追加します。"

#: ../../rst/dev_guide/module_lifecycle.rst
msgid "removed_in"
msgstr "removed_in"

#: ../../rst/dev_guide/module_lifecycle.rst:32
#: ../../rst/dev_guide/module_lifecycle.rst:63
msgid "A ``string``, such as ``\"2.10\"``; the version of Ansible where the module will be replaced with a docs-only module stub. Usually current release +4. Mutually exclusive with :removed_by_date:."
msgstr "``\"2.10\"`` などの ``string`` (モジュールがドキュメントのみのモジュールスタブに置き換えられる Ansible のバージョン)。通常、現在のリリース +4 になります。:removed_by_date: と相互に排他的です。"

#: ../../rst/dev_guide/module_lifecycle.rst
msgid "remove_by_date"
msgstr "remove_by_date"

#: ../../rst/dev_guide/module_lifecycle.rst:33
#: ../../rst/dev_guide/module_lifecycle.rst:64
msgid "(Added in ansible-base 2.10). An ISO 8601 formatted date when the module will be removed. Usually 2 years from the date the module is deprecated. Mutually exclusive with :removed_in:."
msgstr "(ansible-base 2.10 に追加されます)。モジュールの削除時に ISO 8601 形式の日付。通常は、モジュールが非推奨になってから 2 年間となります。このモジュールでは、:removed_in: と相互排他的になります。"

#: ../../rst/dev_guide/module_lifecycle.rst
msgid "why"
msgstr "理由"

#: ../../rst/dev_guide/module_lifecycle.rst:34
#: ../../rst/dev_guide/module_lifecycle.rst:65
msgid "Optional string that used to detail why this has been removed."
msgstr "これが削除された理由の詳細に使用される任意の文字列です。"

#: ../../rst/dev_guide/module_lifecycle.rst
msgid "alternative"
msgstr "代替方法"

#: ../../rst/dev_guide/module_lifecycle.rst:35
#: ../../rst/dev_guide/module_lifecycle.rst:66
msgid "Inform users they should do instead, for example, ``Use M(whatmoduletouseinstead) instead.``."
msgstr "ユーザーが代わりにすべきことを通知します (例: ``Use M(whatmoduletouseinstead) instead.``)。"

#: ../../rst/dev_guide/module_lifecycle.rst:37
msgid "For an example of documenting deprecation, see this `PR that deprecates multiple modules <https://github.com/ansible/ansible/pull/43781/files>`_. Some of the elements in the PR might now be out of date."
msgstr "ドキュメントの非推奨の例は、「`複数のモジュールを非推奨にする PR <https://github.com/ansible/ansible/pull/43781/files>`_」を参照してください。PR の一部の要素が最新でない可能性があります。"

#: ../../rst/dev_guide/module_lifecycle.rst:41
msgid "Deprecating modules and plugins in a collection"
msgstr "コレクションでのモジュールおよびプラグインの非推奨化"

#: ../../rst/dev_guide/module_lifecycle.rst:43
msgid "To deprecate a module in a collection, you must:"
msgstr "コレクションでモジュールを非推奨にするには、以下を行う必要があります。"

#: ../../rst/dev_guide/module_lifecycle.rst:45
msgid "Add a ``deprecation`` entry to ``plugin_routing`` in ``meta/runtime.yml``. For example, to deprecate the module ``old_cloud``, add:"
msgstr "``meta/runtime.yml`` の ``plugin_routing`` に ``deprecation`` エントリーを追加します。たとえば、モジュール ``old_cloud`` を非推奨にするには、以下を追加します。"

#: ../../rst/dev_guide/module_lifecycle.rst:56
msgid "For other plugin types, you have to replace ``modules:`` with ``<plugin_type>:``, for example ``lookup:`` for lookup plugins."
msgstr "他のプラグインタイプの場合、``modules:`` を ``<plugin_type>:`` に置き換える必要があります (検索プラグインの場合は ``lookup:`` など)。"

#: ../../rst/dev_guide/module_lifecycle.rst:58
msgid "Instead of ``removal_version``, you can also use ``removal_date`` with an ISO 8601 formatted date after which the module will be removed in a new major version of the collection."
msgstr "``removal_version`` の代わりに、コレクションの新しいメジャーバージョンでモジュールが削除されるまでの ISO 8601 形式の日付を入れた ``removal_date`` を使用することもできます。"

#: ../../rst/dev_guide/module_lifecycle.rst:60
msgid "Mention the deprecation in the relevant changelog. If the collection uses ``antsibull-changelog``, create a changelog fragment with a section ``deprecated_features``."
msgstr "関連する変更ログで非推奨になったことを説明します (コレクションが ``antsibull-changelog`` を使用する場合は、セクション ``deprecated_features`` を指定して changelog フラグメントを作成します)。"

#: ../../rst/dev_guide/module_lifecycle.rst:61
msgid "Add ``deprecated:`` to the documentation of the module or plugin with the following sub-values:"
msgstr "以下のサブ値を含むモジュールまたはプラグインのドキュメントに ``deprecated:`` を追加します。"

#: ../../rst/dev_guide/module_lifecycle.rst:69
msgid "Changing a module or plugin name in the Ansible main repository"
msgstr "Ansible メインリポジトリーのモジュールまたはプラグイン名の変更"

#: ../../rst/dev_guide/module_lifecycle.rst:71
msgid "You can also rename a module and keep a deprecated alias to the old name by using a symlink that starts with _. This example allows the ``stat`` module to be called with ``fileinfo``, making the following examples equivalent::"
msgstr "_ で始まるシンボリックリンクを使用して、モジュールの名前を変更し、非推奨のエイリアスを古い名前に保つこともできます。この例では、``stat`` モジュールを ``fileinfo`` で呼び出すことができるため、次の例は同等になります。"

#: ../../rst/dev_guide/module_lifecycle.rst:81
msgid "Renaming a module or plugin in a collection, or redirecting a module or plugin to another collection"
msgstr "コレクションでのモジュールまたはプラグインの名前変更、またはモジュールまたはプラグインを別のコレクションにリダイレクト"

#: ../../rst/dev_guide/module_lifecycle.rst:83
msgid "To rename a module or plugin in a collection, or to redirect a module or plugin to another collection, you need to add a ``redirect`` entry to ``plugin_routing`` in ``meta/runtime.yml``. For example, to redirect the module ``old_cloud`` to ``foo.bar.new_cloud``, add:"
msgstr "コレクションでモジュールまたはプラグインの名前を変更するか、モジュールまたはプラグインを別のコレクションにリダイレクトするには、``redirect`` エントリーを、``meta/runtime.yml`` の ``plugin_routing`` に追加する必要があります。たとえば、モジュール ``old_cloud`` を ``foo.bar.new_cloud`` にリダイレクトする場合は、以下を追加します。"

#: ../../rst/dev_guide/module_lifecycle.rst:92
msgid "If you want to deprecate the old name, add a ``deprecation:`` entry (see above):"
msgstr "古い名前を非推奨にするには、``deprecation:`` エントリーを追加します (上記を参照)。"

#: ../../rst/dev_guide/module_lifecycle.rst:104
msgid "You need to use the Fully Qualified Collection Name (FQCN) of the new module/plugin name, even if it is located in the same collection as the redirect. By using a FQCN from another collection, you redirect the module/plugin to that collection."
msgstr "新規モジュール/プラグイン名の完全修飾コレクション名 (FQCN) を使用する必要があります。これは、リダイレクトと同じコレクションにある場合でも、別のコレクションから FQCN を使用し、モジュール/プラグインをそのコレクションにリダイレクトします。"

#: ../../rst/dev_guide/module_lifecycle.rst:106
msgid "If you need to support Ansible 2.9, please note that Ansible 2.9 does not know about ``meta/runtime.yml``. With Ansible 2.9 you can still rename plugins and modules inside one collection by using symbolic links. Note that ansible-base 2.10, ansible-core 2.11, and newer will prefer ``meta/runtime.yml`` entries over symbolic links."
msgstr "Ansible 2.9 をサポートする必要がある場合、Ansible 2.9 は ``meta/runtime.yml`` を認識しない点に注意してください。Ansible 2.9 では、シンボリックリンクを使用して、1 つのコレクション内のプラグインとモジュールの名前を変更できます。ansible-base 2.10、ansible-core 2.11 以降はシンボリックリンクよりも ``meta/runtime.yml`` エントリーを使用することが推奨されます。"

#: ../../rst/dev_guide/module_lifecycle.rst:110
msgid "Tombstoning a module or plugin in a collection"
msgstr "コレクションでモジュールまたはプラグインを破棄"

#: ../../rst/dev_guide/module_lifecycle.rst:112
msgid "To remove a deprecated module or plugin from a collection, you need to tombstone it:"
msgstr "コレクションから非推奨のモジュールまたはプラグインを削除するには、それを破棄する必要があります。"

#: ../../rst/dev_guide/module_lifecycle.rst:114
msgid "Remove the module or plugin file with related files like tests, documentation references, and documentation."
msgstr "テスト、ドキュメント参照、ドキュメントなど、関連ファイルでモジュールまたはプラグインファイルを削除します。"

#: ../../rst/dev_guide/module_lifecycle.rst:115
msgid "Add a tombstone entry in ``meta/runtime.yml``. For example, to tombstone the module ``old_cloud``, add:"
msgstr "``meta/runtime.yml`` に tombstone エントリーを追加します。たとえば、モジュール ``old_cloud`` を廃棄するには、以下を追加します。"

#: ../../rst/dev_guide/module_lifecycle.rst:126
msgid "Instead of ``removal_version``, you can also use ``removal_date`` with an ISO 8601 formatted date. The date should be the date of the next major release."
msgstr "``removal_version`` の代わりに、ISO 8601 形式の日付を入れた ``removal_date`` を使用することもできます。この日付は、次のメジャーリリースの日付である必要があります。"

#: ../../rst/dev_guide/overview_architecture.rst:3
msgid "Ansible architecture"
msgstr "Ansible アーキテクチャー"

#: ../../rst/dev_guide/overview_architecture.rst:5
msgid "Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs."
msgstr "Ansible は、クラウドプロビジョニング、設定管理、アプリケーションのデプロイメント、サービス内オーケストレーション、およびその他の IT のニーズを自動化する非常にシンプルな IT 自動化エンジンです。"

#: ../../rst/dev_guide/overview_architecture.rst:7
msgid "Being designed for multi-tier deployments since day one, Ansible models your IT infrastructure by describing how all of your systems inter-relate, rather than just managing one system at a time."
msgstr "Ansible は、リリースされたその日から多層デプロイメント用に設計されており、システムを 1 つずつ管理する代わりに、すべてのシステムがどのように相互に関連しているかを記述することで、IT インフラストラクチャーをモデル化します。"

#: ../../rst/dev_guide/overview_architecture.rst:9
msgid "It uses no agents and no additional custom security infrastructure, so it's easy to deploy - and most importantly, it uses a very simple language (YAML, in the form of Ansible Playbooks) that allow you to describe your automation jobs in a way that approaches plain English."
msgstr "エージェントを使用せず、カスタムセキュリティーインフラストラクチャーを追加しないため、簡単にデプロイメントできます。最も重要なことは、非常に単純な言語 (YAML を Ansible Playbook の形式で使用) を使用しているため、分かりやすい英語に近づける方法で自動化ジョブを記述できます。"

#: ../../rst/dev_guide/overview_architecture.rst:11
msgid "In this section, we'll give you a really quick overview of how Ansible works so you can see how the pieces fit together."
msgstr "本セクションでは、Ansible の動作の概要を簡単に説明します。これにより各ピースがどのように組み合わされているかを確認できます。"

#: ../../rst/dev_guide/overview_architecture.rst:17
msgid "Modules"
msgstr "モジュール"

#: ../../rst/dev_guide/overview_architecture.rst:19
msgid "Ansible works by connecting to your nodes and pushing out scripts called \"Ansible modules\" to them. Most modules accept parameters that describe the desired state of the system. Ansible then executes these modules (over SSH by default), and removes them when finished. Your library of modules can reside on any machine, and there are no servers, daemons, or databases required."
msgstr "Ansible は、ノードに接続し、「Ansible モジュール」と呼ばれるスクリプトをノードにプッシュすることで機能します。ほとんどのモジュールは、システムの希望の状態を記述するパラメーターを受け入れます。その後、Ansible はこれらのモジュールを (デフォルトでは SSH 上で) 実行して、終了すると削除されます。モジュールのライブラリーはどのマシンにも配置でき、サーバー、デーモン、またはデータベースは必要ありません。"

#: ../../rst/dev_guide/overview_architecture.rst:22
msgid "You can :ref:`write your own modules <developing_modules_general>`, though you should first consider :ref:`whether you should <developing_modules>`. Typically you'll work with your favorite terminal program, a text editor, and probably a version control system to keep track of changes to your content. You may write specialized modules in any language that can return JSON (Ruby, Python, bash, and so on)."
msgstr ":ref:`独自のモジュールを記述 <developing_modules_general>` ができますが、最初に :ref:`記述すべきかどうか <developing_modules>` を検討する必要があります。通常、任意のターミナルプログラム、テキストエディター、およびおそらくバージョン管理システムを使用して、コンテンツへの変更を追跡します。JSON を返すことができる任意の言語 (Ruby、Python、bash など) で特殊なモジュールを作成できます。"

#: ../../rst/dev_guide/overview_architecture.rst:25
msgid "Module utilities"
msgstr "モジュールユーティリティー"

#: ../../rst/dev_guide/overview_architecture.rst:27
msgid "When multiple modules use the same code, Ansible stores those functions as module utilities to minimize duplication and maintenance. For example, the code that parses URLs is ``lib/ansible/module_utils/url.py``. You can :ref:`write your own module utilities <developing_module_utilities>` as well. Module utilities may only be written in Python or in PowerShell."
msgstr "複数のモジュールが同じコードを使用する場合は、Ansible がこの機能をモジュールユーティリティーとして保存し、重複とメンテナンスを最小限に抑えます。たとえば、URL を解析するコードは ``lib/ansible/module_utils/url.py`` となります。:ref:`独自のモジュールユーティリティーを記述 <developing_module_utilities>` をすることもできます。モジュールユーティリティーは、Python または PowerShell でのみ記述できます。"

#: ../../rst/dev_guide/overview_architecture.rst:30
msgid "Plugins"
msgstr "プラグイン"

#: ../../rst/dev_guide/overview_architecture.rst:32
msgid ":ref:`Plugins <plugins_lookup>` augment Ansible's core functionality. While modules execute on the target system in separate processes (usually that means on a remote system), plugins execute on the control node within the ``/usr/bin/ansible`` process. Plugins offer options and extensions for the core features of Ansible - transforming data, logging output, connecting to inventory, and more. Ansible ships with a number of handy plugins, and you can easily :ref:`write your own <developing_plugins>`. For example, you can write an :ref:`inventory plugin <developing_inventory>` to connect to any datasource that returns JSON. Plugins must be written in Python."
msgstr ":ref:`Plugins <plugins_lookup>` は、Ansible のコア機能を拡張するものです。モジュールがターゲットシステムの別のプロセス (通常はリモートシステム上) で実行されるのに対し、プラグインは、``/usr/bin/ansible`` プロセス内のコントロールノードで実行されます。プラグインは、データの変換、出力のロギング、インベントリーへの接続など、Ansible のコア機能のオプションや拡張機能を提供します。Ansible には便利なプラグインが多数同梱されており、簡単に :ref:`自作 <developing_plugins>` できます。たとえば、JSON を返すあらゆるデータソースに接続するための :ref:`inventory プラグイン <developing_inventory>` を記述することができます。プラグインは Python で記述されている必要があります。"

#: ../../rst/dev_guide/overview_architecture.rst:35
msgid "Inventory"
msgstr "インベントリー"

#: ../../rst/dev_guide/overview_architecture.rst:37
msgid "By default, Ansible represents the machines it manages in a file (INI, YAML, and so on) that puts all of your managed machines in groups of your own choosing."
msgstr "デフォルトでは、Ansible は、自身が選択したグループにすべての管理マシンを配置するファイル (INI、YAML など) で管理するマシンを表します。"

#: ../../rst/dev_guide/overview_architecture.rst:39
msgid "To add new machines, there is no additional SSL signing server involved, so there's never any hassle deciding why a particular machine didn't get linked up due to obscure NTP or DNS issues."
msgstr "新しいマシンを追加する場合、追加の SSL 署名サーバーはないため、不明瞭な NTP または DNS の問題が原因で特定のマシンがリンクされなかった理由を判断するのに苦労することはありません。"

#: ../../rst/dev_guide/overview_architecture.rst:41
msgid "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."
msgstr "インフラストラクチャーに信頼できる別のソースがある場合は、Ansible もこれに接続できます。Ansible は、EC2、Rackspace、OpenStack などのソースからインベントリー、グループ、および変数情報を取り出すことができます。"

#: ../../rst/dev_guide/overview_architecture.rst:43
msgid "Here's what a plain text inventory file looks like:"
msgstr "プレーンテキストのインベントリーファイルは次のようになります。"

#: ../../rst/dev_guide/overview_architecture.rst:56
msgid "Once inventory hosts are listed, variables can be assigned to them in simple text files (in a subdirectory called 'group_vars/' or 'host_vars/' or directly in the inventory file."
msgstr "インベントリーホストの一覧が作成されると、単純なテキストファイル形式で (「group_vars/」または「host_vars/」という名前のサブディレクトリー内、またはインベントリーファイルに直接) 割り当てることができます。"

#: ../../rst/dev_guide/overview_architecture.rst:58
msgid "Or, as already mentioned, use a dynamic inventory to pull your inventory from data sources like EC2, Rackspace, or OpenStack."
msgstr "または、上述のように、動的インベントリーを使用して、EC2、Rackspace、OpenStack のようなデータソースからインベントリーをプルすることもできます。"

#: ../../rst/dev_guide/overview_architecture.rst:61
msgid "Playbooks"
msgstr "Playbook"

#: ../../rst/dev_guide/overview_architecture.rst:63
msgid "Playbooks can finely orchestrate multiple slices of your infrastructure topology, with very detailed control over how many machines to tackle at a time.  This is where Ansible starts to get most interesting."
msgstr "Playbook は、インフラストラクチャートポロジーの複数のスライスを細かく調整 (オーケストレーション) することができ、同時に取り組むマシンの数を非常に細かく制御することができます。ここからが、Ansible で最も魅力的な点になります。"

#: ../../rst/dev_guide/overview_architecture.rst:65
msgid "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."
msgstr "Ansible のオーケストレーションへのアプローチは、細かく調整された簡素化の 1 つです。通常、自動化コードは今後何年にも渡って完全に理解できるものであり、特別な構文や機能について覚えておくべきことはほとんどないためです。"

#: ../../rst/dev_guide/overview_architecture.rst:67
msgid "Here's what a simple playbook looks like:"
msgstr "以下は単純な Playbook の例です。"

#: ../../rst/dev_guide/overview_architecture.rst:86
msgid "The Ansible search path"
msgstr "Ansible 検索パス"

#: ../../rst/dev_guide/overview_architecture.rst:88
msgid "Modules, module utilities, plugins, playbooks, and roles can live in multiple locations. If you write your own code to extend Ansible's core features, you may have multiple files with similar or the same names in different locations on your Ansible control node. The search path determines which of these files Ansible will discover and use on any given playbook run."
msgstr "モジュール、モジュールユーティリティー、プラグイン、Playbook、およびロールは複数の場所に置くことができます。Ansible のコア機能を拡張するために独自のコードを作成する場合は、Ansible コントロールノードの異なる場所に同じ名前または類似する名前を持つファイルが複数存在する場合があります。検索パスにより、Ansible が特定の Playbook の実行で検出して使用するこれらのファイルが決まります。"

#: ../../rst/dev_guide/overview_architecture.rst:91
msgid "Ansible's search path grows incrementally over a run. As Ansible finds each playbook and role included in a given run, it appends any directories related to that playbook or role to the search path. Those directories remain in scope for the duration of the run, even after the playbook or role has finished executing. Ansible loads modules, module utilities, and plugins in this order:"
msgstr "Ansible の検索パスは、実行中に徐々に大きくなります。Ansible は、特定の実行に含まれる各 Playbook とロールを見つけると、その Playbook またはロールに関連するディレクトリーを検索パスに追加します。これらのディレクトリーは、Playbook またはロールの実行が終了した後でも、実行中はスコープ内に留まります。Ansible は、モジュール、モジュールユーティリティー、およびプラグインを次の順序で読み込みます。"

#: ../../rst/dev_guide/overview_architecture.rst:97
msgid "Directories adjacent to a playbook specified on the command line. If you run Ansible with ``ansible-playbook /path/to/play.yml``, Ansible appends these directories if they exist:"
msgstr "コマンドラインで指定した Playbook に隣接するディレクトリー。``ansible-playbook /path/to/play.yml`` で Ansible を実行し、そのディレクトリーが存在する場合は、Ansible がそのディレクトリーを追加します。"

#: ../../rst/dev_guide/overview_architecture.rst:105
msgid "Directories adjacent to a playbook that is statically imported by a playbook specified on the command line. If ``play.yml`` includes ``- import_playbook: /path/to/subdir/play1.yml``, Ansible appends these directories if they exist:"
msgstr "コマンドラインで指定された Playbook によって静的にインポートされる Playbook に隣接するディレクトリー。``play.yml`` に ``- import_playbook: /path/to/subdir/play1.yml`` が含まれていて、これらのディレクトリーが存在する場合は、Ansible がそのディレクトリーを追加します。"

#: ../../rst/dev_guide/overview_architecture.rst:115
msgid "Subdirectories of a role directory referenced by a playbook. If ``play.yml`` runs ``myrole``, Ansible appends these directories if they exist:"
msgstr "Playbook によって参照されるロールディレクトリーのサブディレクトリー。``play.yml`` が ``myrole`` を実行し、次のディレクトリーが存在する場合は、Ansible がそのディレクトリーを追加します。"

#: ../../rst/dev_guide/overview_architecture.rst:124
msgid "Directories specified as default paths in ``ansible.cfg`` or by the related environment variables, including the paths for the various plugin types. See :ref:`ansible_configuration_settings` for more information. Sample ``ansible.cfg`` fields:"
msgstr "``ansible.cfg`` のデフォルトパスとして、またはさまざまなプラグインタイプのパスなど、関連する環境変数により指定されたディレクトリー。詳細は、「:ref:`ansible_configuration_settings`」を参照してください。サンプルの ``ansible.cfg`` フィールドは以下のようになります。"

#: ../../rst/dev_guide/overview_architecture.rst:135
msgid "Sample environment variables:"
msgstr "以下は、環境変数の例となります。"

#: ../../rst/dev_guide/overview_architecture.rst:144
msgid "The standard directories that ship as part of the Ansible distribution."
msgstr "Ansible ディストリビューションに同梱される標準ディレクトリー。"

#: ../../rst/dev_guide/overview_architecture.rst:148
msgid "Modules, module utilities, and plugins in user-specified directories will override the standard versions. This includes some files with generic names. For example, if you have a file named ``basic.py`` in a user-specified directory, it will override the standard ``ansible.module_utils.basic``."
msgstr "ユーザーが指定したディレクトリーにあるモジュール、モジュールユーティリティー、およびプラグインは標準バージョンを上書きします。これには、一般的な名前のファイルも含まれます。たとえば、ユーザー指定のディレクトリーに ``basic.py`` という名前のファイルがある場合は、標準の ``ansible.module_utils.basic`` を上書きします。"

#: ../../rst/dev_guide/overview_architecture.rst:153
msgid "If you have more than one module, module utility, or plugin with the same name in different user-specified directories, the order of commands at the command line and the order of includes and roles in each play will affect which one is found and used on that particular play."
msgstr "同じ名前のモジュール、モジュールユーティリティー、またはプラグインが複数のユーザー指定ディレクトリーにある場合、コマンドラインでのコマンドの順序や、各プレイでのインクルードとロールの順序は、その特定のプレイでどのモジュールが見つかり、使用されるかによって異なります。"

#: ../../rst/dev_guide/platforms/aws_guidelines.rst:5
msgid "Guidelines for Ansible Amazon AWS module development"
msgstr "Ansible Amazon AWS モジュール開発のガイドライン"

#: ../../rst/dev_guide/platforms/aws_guidelines.rst:7
msgid "This guide has moved to :ref:`ansible_collections.amazon.aws.docsite.dev_guide_intro`."
msgstr "このガイドは :ref:`ansible_collections.amazon.aws.docsite.dev_guide_intro` に移動しました。"

#: ../../rst/dev_guide/platforms/openstack_guidelines.rst:4
msgid "OpenStack Ansible Modules"
msgstr "OpenStack Ansible モジュール"

#: ../../rst/dev_guide/platforms/openstack_guidelines.rst:6
msgid "Please see the `OpenStack guidelines <https://opendev.org/openstack/ansible-collections-openstack/src/branch/master/docs/openstack_guidelines.rst>`_,  for further information."
msgstr "詳細は、`OpenStack ガイドライン <https://opendev.org/openstack/ansible-collections-openstack/src/branch/master/docs/openstack_guidelines.rst>`_ を参照してください。"

#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:4
msgid "oVirt Ansible Modules"
msgstr "oVirt Ansible モジュール"

#: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:7
msgid "See the `ovirt.ovirt collection documentation <https://github.com/oVirt/ovirt-ansible-collection/blob/master/README-developers.md>`_ for details on how to contribute to this collection."
msgstr "このコレクションへの貢献方法は、`ovirt.ovirt collection documentation <https://github.com/oVirt/ovirt-ansible-collection/blob/master/README-developers.md>`_ を参照してください。"

#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:5
msgid "Guidelines for VMware module development"
msgstr "VMware モジュール開発のガイドライン"

#: ../../rst/dev_guide/platforms/vmware_guidelines.rst:7
msgid "This guide has moved to :ref:`ansible_collections.community.vmware.docsite.vmware_ansible_devguide`."
msgstr "このガイドは :ref:`ansible_collections.community.vmware.docsite.vmware_ansible_devguide` に移動しました。"

#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:5
msgid "Guidelines for VMware REST module development"
msgstr "VMware REST モジュール開発のガイドライン"

#: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:7
msgid "This guide has moved to :ref:`ansible_collections.vmware.vmware_rest.docsite.vmware_rest_devguide`."
msgstr "このガイドは :ref:`ansible_collections.vmware.vmware_rest.docsite.vmware_rest_devguide` に移動しました。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:4
msgid "Basic rules"
msgstr "基本ルール"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:9
msgid "Use standard American English"
msgstr "標準的なアメリカ英語を使用する"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:10
msgid "Ansible uses Standard American English. Watch for common words that are spelled differently in American English (color vs colour, organize vs organise, and so on)."
msgstr "Ansible は標準的なアメリカ英語を使用します。アメリカ英語では綴りが異なる一般的な単語に注意してください (color と colour、organize と organise など)。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:13
msgid "Write for a global audience"
msgstr "世界中の読者に向けて書く"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:14
msgid "Everything you say should be understandable by people of different backgrounds and cultures. Avoid idioms and regionalism and maintain a neutral tone that cannot be misinterpreted. Avoid attempts at humor."
msgstr "記載する内容は、生い立ちや文化が違っても理解できるものでなければなりません。イディオムや地域主義は使用せず、誤って解釈されない中立的な表現を使用します。ユーモアな表現は使用しないでください。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:17
msgid "Follow naming conventions"
msgstr "命名規則に従う"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:18
msgid "Always follow naming conventions and trademarks."
msgstr "命名規則と商標には常に従ってください。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:23
msgid "Use clear sentence structure"
msgstr "明確な文構造を使用する"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:24
msgid "Clear sentence structure means:"
msgstr "明確な文法構造とは、以下のようになります。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:26
msgid "Start with the important information first."
msgstr "重要な情報を最初に示します。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:27
msgid "Avoid padding/adding extra words that make the sentence harder to understand."
msgstr "文章の理解が難しくなるような単語は使用しないでください。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:28
msgid "Keep it short - Longer sentences are harder to understand."
msgstr "文章は短くします。文章が長くなればなるほど、理解が難しくなります。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:30
msgid "Some examples of improving sentences:"
msgstr "たとえば、以下のように改善できます。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:33
#: ../../rst/dev_guide/style_guide/basic_rules.rst:39
msgid "Bad:"
msgstr "問題がある文章: "

#: ../../rst/dev_guide/style_guide/basic_rules.rst:33
msgid "The unwise walking about upon the area near the cliff edge may result in a dangerous fall and therefore it is recommended that one remains a safe distance to maintain personal safety."
msgstr "The unwise walking about upon the area near the cliff edge may result in a dangerous fall and therefore it is recommended that one remains a safe distance to maintain personal safety. (崖の端近くを歩き回ると、下に落ちる危険があります。安全を維持するために安全な距離を保つことをお勧めします。)"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:36
#: ../../rst/dev_guide/style_guide/basic_rules.rst:42
msgid "Better:"
msgstr "改善例: "

#: ../../rst/dev_guide/style_guide/basic_rules.rst:36
msgid "Danger! Stay away from the cliff."
msgstr "Danger! Stay away from the cliff. (危険です。崖から離れてください。)"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:39
msgid "Furthermore, large volumes of water are also required for the process of extraction."
msgstr "Furthermore, large volumes of water are also required for the process of extraction. (また、抜歯のプロセスには、水が大量に必要になります。)"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:42
msgid "Extraction also requires large volumes of water."
msgstr "Extraction also requires large volumes of water. (抜歯には、大量の水が必要です。)"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:45
msgid "Avoid verbosity"
msgstr "冗長を避ける"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:46
msgid "Write short, succinct sentences. Avoid terms like:"
msgstr "短く簡潔な文章を書きます。以下のような用語は使用しないでください。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:48
msgid "\"...as has been said before,\""
msgstr "「...as has been said before」"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:49
msgid "\"..each and every,\""
msgstr "「...each and every」"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:50
msgid "\"...point in time,\""
msgstr "「...point in time」"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:51
msgid "\"...in order to,\""
msgstr "「...in order to」"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:54
msgid "Highlight menu items and commands"
msgstr "メニュー項目およびコマンドを強調表示する"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:55
msgid "When documenting menus or commands, it helps to **bold** what is important."
msgstr "メニューまたはコマンドを文書化する場合は、重要な内容を **太字** にすると役立ちます。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:57
msgid "For menu procedures, bold the menu names, button names, and so on to help the user find them on the GUI:"
msgstr "メニュー手順では、メニュー名、ボタン名などを太字にして、GUI でその文字を見つけられるようにします。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:59
msgid "On the **File** menu, click **Open**."
msgstr "**ファイル** メニューで、**開く** をクリックします。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:60
msgid "Type a name in the **User Name** field."
msgstr "**ユーザー名** フィールドに名前を入力します。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:61
msgid "In the **Open** dialog box, click **Save**."
msgstr "**開く** ダイアログボックスで、**保存** をクリックします。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:62
msgid "On the toolbar, click the **Open File** icon."
msgstr "ツールバーで、**ファイルを開く** アイコンをクリックします。"

#: ../../rst/dev_guide/style_guide/basic_rules.rst:64
msgid "For code or command snippets, use the RST `code-block directive <https://www.sphinx-doc.org/en/1.5/markup/code.html#directive-code-block>`_::"
msgstr "code または command スニペットの場合は、RST の `code-block ディレクティブ <https://www.sphinx-doc.org/en/1.5/markup/code.html#directive-code-block>`_ を使用します。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:3
msgid "Grammar and Punctuation"
msgstr "文法および句読点"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:6
msgid "Common Styles and Usage, and Common Mistakes"
msgstr "一般的なスタイルおよび使用方法、ならびに一般的な間違い"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:9
#: ../../rst/dev_guide/testing/sanity/ignores.rst:50
msgid "Ansible"
msgstr "Ansible"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:10
msgid "Write \"Ansible.\" Not \"Ansible, Inc.\" or \"AnsibleWorks The only exceptions to this rule are when we're writing legal or financial statements."
msgstr "「Ansible, Inc.」または「AnsibleWorks」とせず、「Ansible」と記述してください。このルールの唯一の例外は、法的文書または財務諸表を作成する場合です。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:12
msgid "Never use the logotype by itself in body text. Always keep the same font you are using the rest of the sentence."
msgstr "ロゴマークは、本文で使用しないでください。その他の文章で使用しているフォントを常に使用します。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:14
msgid "A company is singular in the US. In other words, Ansible is an \"it,\" not a \"they.\""
msgstr "米国では、会社は単数形で使用します。つまり、Ansible は、「they」ではなく「it」になります。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:18
msgid "Capitalization"
msgstr "大文字"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:19
msgid "If it's not a real product, service, or department at Ansible, don't capitalize it. Not even if it seems important. Capitalize only the first letter of the first word in headlines."
msgstr "Ansible の実際の製品、サービス、または部門ではない場合は、大文字にしないでください。見出しの最初の単語の最初の文字だけを大文字にします。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:22
msgid "Colon"
msgstr "コロン"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:23
msgid "A colon is generally used before a list or series: - The Triangle Area consists of three cities: Raleigh, Durham, and Chapel Hill."
msgstr "通常、コロンは、リストまたは一連の要素の前に使用されます。- The Triangle Area consists of three cities: Raleigh, Durham, and Chapel Hill."

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:26
msgid "But not if the list is a complement or object of an element in the sentence: - Before going on vacation, be sure to (1) set the alarm, (2) cancel the newspaper, and (3) ask a neighbor to collect your mail."
msgstr "ただし、リストが、文内の要素の補語または目的語の場合は、以下のようにします。Before going on vacation, be sure to (1) set the alarm, (2) cancel the newspaper, and (3) ask a neighbor to collect your mail."

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:29
msgid "Use a colon after \"as follows\" and \"the following\" if the related list comes immediately after: wedge The steps for changing directories are as follows:"
msgstr "直後に関連するリストを追加する場合は、「as follows」および「the following」(次のとおり) の後にコロンを使用します。The steps for changing directories are as follows:"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:32
msgid "Open a terminal."
msgstr "Open a terminal."

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:33
msgid "Type cd..."
msgstr "Type cd..."

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:35
msgid "Use a colon to introduce a bullet list (or dash, or icon/symbol of your choice):"
msgstr "コロンを使用して、箇条書きリスト (ダッシュ、アイコンまたは記号を使用) を追加します。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:37
msgid "In the Properties dialog box, you'll find the following entries:"
msgstr "In the Properties dialog box, you'll find the following entries:"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:39
msgid "Connection name"
msgstr "Connection name"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:40
msgid "Count"
msgstr "Count"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:41
msgid "Cost per item"
msgstr "Cost per item"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:45
msgid "Commas"
msgstr "コンマ"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:46
msgid "Use serial commas, the comma before the \"and\" in a series of three or more items:"
msgstr "3 つ以上の項目が続く場合は、「and」の前にコンマを使用します。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:48
msgid "\"Item 1, item 2, and item 3.\""
msgstr "Item 1, item 2, and item 3."

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:51
msgid "It's easier to read that way and helps avoid confusion. The primary exception to this you will see is in PR, where it is traditional not to use serial commas because it is often the style of journalists."
msgstr "これにより読みやすくなり、混乱を避けることができます。これに対する主な例外は PR です。PR では、多くの場合ジャーナリスト向けのスタイルにより、このようなコンマは使用しません。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:53
msgid "Commas are always important, considering the vast difference in meanings of the following two statements."
msgstr "次の 2 つの文章の意味が大きく異なることを考えると、コンマは常に重要です。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:55
msgid "Let's eat, Grandma"
msgstr "Let's eat, Grandma"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:56
msgid "Let's eat Grandma."
msgstr "Let's eat Grandma."

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:58
msgid "Correct punctuation could save Grandma's life."
msgstr "正しい句読点により、おばあさんの命を救うことができます。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:60
msgid "If that does not convince you, maybe this will:"
msgstr "もしくは、以下の例をご覧ください。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:66
msgid "Contractions"
msgstr "縮約"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:67
msgid "Do not use contractions in Ansible documents."
msgstr "Ansible ドキュメントでは、縮約は使用しないでください。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:70
msgid "Em dashes"
msgstr "エムダッシュ (－)"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:71
msgid "When possible, use em-dashes with no space on either side. When full em-dashes aren't available, use double-dashes with no spaces on either side--like this."
msgstr "可能な場合は、両側にスペースを入れずにエムダッシュ (－) を使用します。エムダッシュ (－) が利用できない場合は、両側に空白を入れずに二重ダッシュを使用します。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:73
msgid "A pair of em dashes can be used in place of commas to enhance readability. Note, however, that dashes are always more emphatic than commas."
msgstr "読みやすくするために、コンマの代わりにエムダッシュをペアにして使用できます。ただし、ダッシュはコンマよりも常に強調されることに注意してください。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:75
msgid "A pair of em dashes can replace a pair of parentheses. Dashes are considered less formal than parentheses; they are also more intrusive. If you want to draw attention to the parenthetical content, use dashes. If you want to include the parenthetical content more subtly, use parentheses."
msgstr "エムダッシュのペアは、括弧のペアの代わりに使用することもできます。ダッシュは括弧よりも形式的ではないと見なされ、押しつけがましく感じることもあります。括弧内のコンテンツに注意を引きたい場合は、ダッシュを使用します。括弧内のコンテンツにあまり注意を引きたくない場合は、括弧を使用します。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:78
msgid "When dashes are used in place of parentheses, surrounding punctuation should be omitted. Compare the following examples."
msgstr "括弧の代わりにダッシュを使用する場合は、前後の句読点を省略してください。次の例を比較してください。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:87
msgid "When used in place of parentheses at the end of a sentence, only a single dash is used."
msgstr "文末に括弧の代わりに使用する場合は、ダッシュを 1 つだけ使用します。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:97
msgid "Exclamation points (!)"
msgstr "感嘆符 (!)"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:98
msgid "Do not use them at the end of sentences. An exclamation point can be used when referring to a command, such as the bang (!) command."
msgstr "文末には使用しないでください。感嘆符は、bang (!) などのコマンドを参照する場合に使用できます。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:101
msgid "Gender References"
msgstr "性別の参照"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:102
msgid "Do not use gender-specific pronouns in documentation. It is far less awkward to read a sentence that uses \"they\" and \"their\" rather than \"he/she\" and \"his/hers.\""
msgstr "ドキュメンテーションでは、性別固有の代名詞は使用しないでください。「he/she」や「his/hers」ではなく「they」および「their」を使用する方が適切です。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:104
msgid "It is fine to use \"you\" when giving instructions and \"the user,\" \"new users,\" and so on. in more general explanations."
msgstr "指示を示す場合は「you」と使用し、より一般的な説明では「the user」、「new users」などを使用すると良いでしょう。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:106
msgid "Never use \"one\" in place of \"you\" when writing technical documentation. Using \"one\" is far too formal."
msgstr "テクニカルドキュメントを作成する際は、「you」 の意味で「one」を使用しないでください。「one」を使用すると堅苦しくなります。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:108
msgid "Never use \"we\" when writing. \"We\" aren't doing anything on the user side. Ansible's products are doing the work as requested by the user."
msgstr "書き込み時に「we」は使用しないでください。「we」は、ユーザー側では何も実行しません。Ansible の製品は、ユーザーの要求に応じて作業を行います。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:112
msgid "Hyphen"
msgstr "ハイフン"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:113
msgid "The hyphen's primary function is the formation of certain compound terms. Do not use a hyphen unless it serves a purpose. If a compound adjective cannot be misread or, as with many psychological terms, its meaning is established, a hyphen is not necessary."
msgstr "このハイフンの主な機能は、特定の複合用語の特徴です。目的が満たされない限り、ハイフンは使用しないでください。複合形容詞が間違って解釈されない場合、または多くの心理学用語と同じ様に、その意味が確立されている場合、ハイフンは必要ありません。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:115
msgid "Use hyphens to avoid ambiguity or confusion:"
msgstr "ハイフンは、あいまいさや混乱を回避するために使用します。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:135
msgid "In professionally printed material (particularly books, magazines, and newspapers), the hyphen is used to divide words between the end of one line and the beginning of the next. This allows for an evenly aligned right margin without highly variable (and distracting) word spacing."
msgstr "適切な編集が必要な出版物 (特に本、雑誌、新聞) では、単語が行をまたがる場合にハイフンを使用します。これにより、単語の間隔が大きく変わる (そして気が散る) ことなく、右マージンを均等に揃えることができます。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:139
msgid "Lists"
msgstr "リスト"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:140
msgid "Keep the structure of bulleted lists equivalent and consistent. If one bullet is a verb phrase, they should all be verb phrases. If one is a complete sentence, they should all be complete sentences, and so on."
msgstr "箇条書きの構造を同等かつ一貫性のあるものに保ちます。たとえば、1 つの箇条書きが動詞句である場は、すべての箇条書きが動詞句である必要があります。1 つが完全な文である場合、すべての項目が完全な文である必要があります。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:142
msgid "Capitalize the first word of each bullet. Unless it is obvious that it is just a list of items, such as a list of items like: * computer * monitor * keyboard * mouse"
msgstr "箇条書きでは、それぞれ最初の単語を大文字にします。次のような項目のリストなど、単に項目のリストであることが明らかである場合は除きます (* computer * monitor * keyboard * mouse)。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:148
msgid "When the bulleted list appears within the context of other copy, (unless it's a straight list like the previous example) add periods, even if the bullets are sentence fragments. Part of the reason behind this is that each bullet is said to complete the original sentence."
msgstr "箇条書きが他の文章に含まれる場合は、(上の例のような単純なリストでない限り) 箇条書きが完全な文になっていなくてもピリオドを追加します。これは、各箇条書きが元の文を完了すると言われているためです。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:150
msgid "In some cases where the bullets are appearing independently, such as in a poster or a homepage promotion, they do not need periods."
msgstr "箇条書きがポスターやホームページのプロモーションなどのように独立して示される場合、ピリオドは必要ありません。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:152
msgid "When giving instructional steps, use numbered lists instead of bulleted lists."
msgstr "手順を説明するときは、箇条書きの代わりに番号付きリストを使用してください。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:156
msgid "Months and States"
msgstr "月および州"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:157
msgid "Abbreviate months and states according to AP. Months are only abbreviated if they are used in conjunction with a day. Example: \"The President visited in January 1999.\" or \"The President visited Jan. 12.\""
msgstr "AP に従って、月と州の名前を省略します。月は、日付と組み合わせて使用される場合に限り省略されます。たとえば、「The President visited in January 1999.」または「The President visited Jan. 12.」です。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:159
msgid "Months: Jan., Feb., March, April, May, June, July, Aug., Sept., Nov., Dec."
msgstr "月: Jan.、Feb.、March、April、May、June、July、Aug.、Sept.、Nov.、Dec."

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:161
msgid "States: Ala., Ariz., Ark., Calif., Colo., Conn., Del., Fla., Ga., Ill., Ind., Kan., Ky., La., Md., Mass., Mich., Minn., Miss., Mo., Mont., Neb., Nev., NH, NJ, NM, NY, NC, ND, Okla., Ore., Pa., RI, SC, SD, Tenn., Vt., Va., Wash., W.Va., Wis., Wyo."
msgstr "州: Ala.、Ariz.、Ark.、Calif.、Colo.、Conn.、Del.、Fla.、Ga.、Ill.、Ind.、Kan.、Ky.、La.、Md.、Mass.、Mich.、Minn.、Miss.、Mo.、Mont.、Neb.、Nev.、NH、NJ、NM、NY、NC、ND、Okla.、Ore.、Pa.、RI、SC、SD、Tenn.、Vt.、Va.、Wash.、W.Va.、Wis.、Wyo."

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:164
msgid "Numbers"
msgstr "数字"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:165
msgid "Numbers between one and nine are written out. 10 and above are numerals. The exception to this is writing \"4 million\" or \"4 GB.\" It's also acceptable to use numerals in tables and charts."
msgstr "1 から 9 までの数字が使用されます。10 以上の値は数字を使用します。「4 million」または「4 GB」などは例外となります。また、表やチャートでは数値を使用することもできます。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:168
msgid "Phone Numbers"
msgstr "電話番号"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:170
msgid "Phone number style: 1 (919) 555-0123 x002 and 1 888-GOTTEXT"
msgstr "電話番号の形式: 1 (919) 555-0123 x002 および 1 888-GOTTEXT"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:174
msgid "Quotations (Using Quotation Marks and Writing Quotes)"
msgstr "引用 (引用符の使用と引用の記述)"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:175
msgid "\"Place the punctuation inside the quotes,\" the editor said."
msgstr "\"Place the punctuation inside the quotes,\" the editor said. (「句読点を引用符の中に入れてください」と編集者は言いました)"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:177
msgid "Except in rare instances, use only \"said\" or \"says\" because anything else just gets in the way of the quote itself, and also tends to editorialize."
msgstr "ほとんどの場合は、「said」または「says」だけを使用してください。それ以外は、引用の邪魔になり、編集される傾向があるためです。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:180
msgid "Place the name first right after the quote:"
msgstr "引用の直後に名前を追加します。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:180
msgid "\"I like to write first-person because I like to become the character I'm writing,\" Wally Lamb said."
msgstr "\"I like to write first-person because I like to become the character I'm writing,\" Wally Lamb said. (「私は自分が書いているキャラクターになりたいので、一人称を書くのが好きです」と Wally Lamb は言いました)"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:184
msgid "Not:"
msgstr "以下のようにはしないでください。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:183
msgid "\"I like to write first-person because I like to become the character I'm writing,\" said Wally Lamb."
msgstr "\"I like to write first-person because I like to become the character I'm writing,\" said Wally Lamb."

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:187
msgid "Semicolon"
msgstr "セミコロン"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:188
msgid "Use a semicolon to separate items in a series if the items contain commas:"
msgstr "項目にコンマが含まれている場合は、セミコロンを使用して項目を区切ります。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:190
msgid "Everyday I have coffee, toast, and fruit for breakfast; a salad for lunch; and a peanut butter sandwich, cookies, ice cream, and chocolate cake for dinner."
msgstr "Everyday I have coffee, toast, and fruit for breakfast; a salad for lunch; and a peanut butter sandwich, cookies, ice cream, and chocolate cake for dinner. (私は毎日、朝食にコーヒー、トースト、およびフルーツを食べます。ランチはサラダを食べ、ディナーには、ピーナッツバターのサンドイッチ、クッキー、アイスクリーム、およびチョコレートケーキを食べます)"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:192
msgid "Use a semicolon before a conjunctive adverb (however, therefore, otherwise, namely, for example, and so on): - I think; therefore, I am."
msgstr "接続詞副詞 (however、therefore、otherwise、namely、for example など) の前にセミコロンを使用します。「I think; therefore, I am.」のようにします。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:196
msgid "Spacing after sentences"
msgstr "文の後のスペース"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:197
msgid "Use only a single space after a sentence."
msgstr "文の後には、シングルスペースのみを使用してください。"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:200
msgid "Time"
msgstr "時間"

#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:201
msgid "Time of day is written as \"4 p.m.\""
msgstr "時刻は「4 p.m」とします。"

#: ../../rst/dev_guide/style_guide/index.rst:5
msgid "Ansible documentation style guide"
msgstr "Ansible ドキュメントのスタイルガイド"

#: ../../rst/dev_guide/style_guide/index.rst:7
msgid "Welcome to the Ansible style guide! To create clear, concise, consistent, useful materials on docs.ansible.com, follow these guidelines:"
msgstr "Ansible スタイルガイドにようこそ! docs.ansible.com に、明確および簡潔で、一貫性のある有用なドキュメントを作成するために、以下のガイドラインが指定されています。"

#: ../../rst/dev_guide/style_guide/index.rst:14
msgid "Linguistic guidelines"
msgstr "言語のガイドライン"

#: ../../rst/dev_guide/style_guide/index.rst:16
msgid "We want the Ansible documentation to be:"
msgstr "Ansible ドキュメントでは、以下を目標にしています。"

#: ../../rst/dev_guide/style_guide/index.rst:18
msgid "clear"
msgstr "明確な"

#: ../../rst/dev_guide/style_guide/index.rst:19
msgid "direct"
msgstr "直接的な"

#: ../../rst/dev_guide/style_guide/index.rst:20
msgid "conversational"
msgstr "会話的な"

#: ../../rst/dev_guide/style_guide/index.rst:21
msgid "easy to translate"
msgstr "解釈が容易な"

#: ../../rst/dev_guide/style_guide/index.rst:23
msgid "We want reading the docs to feel like having an experienced, friendly colleague explain how Ansible works."
msgstr "Ansible が提供するドキュメントは、経験豊富で友好的な同僚に Ansible の仕組みを説明してもらっていると感じられるようなものにすることを目標にしています。"

#: ../../rst/dev_guide/style_guide/index.rst:27
msgid "Stylistic cheat-sheet"
msgstr "文体の早見表"

#: ../../rst/dev_guide/style_guide/index.rst:29
msgid "This cheat-sheet illustrates a few rules that help achieve the \"Ansible tone\":"
msgstr "以下の早見表は、「Ansibleのトーン」を実現するのに役立つルールを示しています。"

#: ../../rst/dev_guide/style_guide/index.rst:32
msgid "Rule"
msgstr "**ルール**"

#: ../../rst/dev_guide/style_guide/index.rst:32
msgid "Good example"
msgstr "適切な例"

#: ../../rst/dev_guide/style_guide/index.rst:32
msgid "Bad example"
msgstr "不適切な例"

#: ../../rst/dev_guide/style_guide/index.rst:34
msgid "Use active voice"
msgstr "能動態を使用します。"

#: ../../rst/dev_guide/style_guide/index.rst:34
msgid "You can run a task by"
msgstr "You can run a task by (以下を使用してタスクを実行できます)"

#: ../../rst/dev_guide/style_guide/index.rst:34
msgid "A task can be run by"
msgstr "A task can be run by (タスクは、以下のように実行できます)"

#: ../../rst/dev_guide/style_guide/index.rst:36
msgid "Use the present tense"
msgstr "現在形の使用"

#: ../../rst/dev_guide/style_guide/index.rst:36
msgid "This command creates a"
msgstr "This command creates a (このコマンドにより...が作成されます。)"

#: ../../rst/dev_guide/style_guide/index.rst:36
msgid "This command will create a"
msgstr "This command will create a (このコマンドにより...が作成されます)"

#: ../../rst/dev_guide/style_guide/index.rst:38
msgid "Address the reader"
msgstr "読者に話すように書きます。"

#: ../../rst/dev_guide/style_guide/index.rst:38
msgid "As you expand your inventory"
msgstr "As you expand your inventory (インベントリーを展開します)"

#: ../../rst/dev_guide/style_guide/index.rst:38
msgid "When the number of managed nodes grows"
msgstr "When the number of managed nodes grows (管理ノードの数が増える場合)"

#: ../../rst/dev_guide/style_guide/index.rst:40
msgid "Use standard English"
msgstr "標準英語の使用"

#: ../../rst/dev_guide/style_guide/index.rst:40
msgid "Return to this page"
msgstr "Return to this page (このページに戻る)"

#: ../../rst/dev_guide/style_guide/index.rst:40
msgid "Hop back to this page"
msgstr "Hop back to this page (このページに戻る)"

#: ../../rst/dev_guide/style_guide/index.rst:42
msgid "Use American English"
msgstr "アメリカ英語の使用"

#: ../../rst/dev_guide/style_guide/index.rst:42
msgid "The color of the output"
msgstr "The color of the output (出力の色)"

#: ../../rst/dev_guide/style_guide/index.rst:42
msgid "The colour of the output"
msgstr "The colour of the output (出力の色)"

#: ../../rst/dev_guide/style_guide/index.rst:46
msgid "Header case"
msgstr "ヘッダーの書式"

#: ../../rst/dev_guide/style_guide/index.rst:48
msgid "Headers should be written in sentence case. For example, this section's title is ``Header case``, not ``Header Case`` or ``HEADER CASE``."
msgstr "ヘッダーは文で使用される書式で記述する必要があります。たとえば、このセクションのタイトルは、``Header Case`` や ``HEADER CASE`` ではなく、``Header case`` と記述します。"

#: ../../rst/dev_guide/style_guide/index.rst:53
msgid "Avoid using Latin phrases"
msgstr "ラテン語のフレーズを使用しない"

#: ../../rst/dev_guide/style_guide/index.rst:55
msgid "Latin words and phrases like ``e.g.`` or ``etc.`` are easily understood by English speakers. They may be harder to understand for others and are also tricky for automated translation."
msgstr "``e.g.``、``etc.`` のようなラテン語やフレーズは、英語話者であれば簡単に理解できます。ただし、その他の人にとっては理解が難しい場合もあり、自動翻訳の際にも注意が必要になります。"

#: ../../rst/dev_guide/style_guide/index.rst:59
msgid "Use the following English terms in place of Latin terms or abbreviations:"
msgstr "したがって、ラテン語の用語または略語の代わりに、英語の用語を使用します。"

#: ../../rst/dev_guide/style_guide/index.rst:62
msgid "Latin"
msgstr "ラテン語"

#: ../../rst/dev_guide/style_guide/index.rst:62
msgid "English"
msgstr "英語"

#: ../../rst/dev_guide/style_guide/index.rst:64
msgid "i.e"
msgstr "i.e (言い換えると)"

#: ../../rst/dev_guide/style_guide/index.rst:64
msgid "in other words"
msgstr "in other words (言い換えると)"

#: ../../rst/dev_guide/style_guide/index.rst:66
#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:89
msgid "e.g."
msgstr "e.g. (たとえば)"

#: ../../rst/dev_guide/style_guide/index.rst:66
msgid "for example"
msgstr "for example (たとえば)"

#: ../../rst/dev_guide/style_guide/index.rst:68
msgid "etc"
msgstr "etc (など)"

#: ../../rst/dev_guide/style_guide/index.rst:68
msgid "and so on"
msgstr "and so on (など)"

#: ../../rst/dev_guide/style_guide/index.rst:70
msgid "via"
msgstr "via (により)"

#: ../../rst/dev_guide/style_guide/index.rst:70
msgid "by/ through"
msgstr "by/ through (により)"

#: ../../rst/dev_guide/style_guide/index.rst:72
msgid "vs./versus"
msgstr "vs./versus (対)"

#: ../../rst/dev_guide/style_guide/index.rst:72
msgid "rather than/against"
msgstr "rather than/against (対)"

#: ../../rst/dev_guide/style_guide/index.rst:77
msgid "reStructuredText guidelines"
msgstr "reStructuredText のガイドライン"

#: ../../rst/dev_guide/style_guide/index.rst:79
msgid "The Ansible documentation is written in reStructuredText and processed by Sphinx. We follow these technical or mechanical guidelines on all rST pages:"
msgstr "Ansible ドキュメントは reStructuredText で記述され、Sphinx によって処理されます。すべての rST ページに対して、以下の技術的または機械的なガイドラインが指定されています。"

#: ../../rst/dev_guide/style_guide/index.rst:85
msgid "Header notation"
msgstr "ヘッダーの表記法"

#: ../../rst/dev_guide/style_guide/index.rst:87
msgid "`Section headers in reStructuredText <https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#sections>`_ can use a variety of notations. Sphinx will 'learn on the fly' when creating a hierarchy of headers. To make our documents easy to read and to edit, we follow a standard set of header notations. We use:"
msgstr "`Section headers in reStructuredText <https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#sections>`_ は、さまざまな表記を使用できます。Sphinx は、ヘッダーの階層を作成するときに「オンザフライで学習」します。ドキュメントを読みやすく、編集できるようにするために、標準のヘッダー表記法に従います。以下を使用します。"

#: ../../rst/dev_guide/style_guide/index.rst:93
msgid "``###`` with overline, for parts:"
msgstr "上線付き (各部分の場合): ``###``"

#: ../../rst/dev_guide/style_guide/index.rst:101
msgid "``***`` with overline, for chapters:"
msgstr "上線付き (章の場合): ``***``"

#: ../../rst/dev_guide/style_guide/index.rst:109
msgid "``===`` for sections:"
msgstr "セクションの場合: ``===``"

#: ../../rst/dev_guide/style_guide/index.rst:116
msgid "``---`` for subsections:"
msgstr "サブセクションの場合: ``---``"

#: ../../rst/dev_guide/style_guide/index.rst:123
msgid "``^^^`` for sub-subsections:"
msgstr "サブサブセクションの場合: ``^^^``"

#: ../../rst/dev_guide/style_guide/index.rst:130
msgid "``\"\"\"`` for paragraphs:"
msgstr "パラグラフの場合: ``\"\"\"``"

#: ../../rst/dev_guide/style_guide/index.rst:139
msgid "Syntax highlighting - Pygments"
msgstr "構文の強調表示 - Pygment"

#: ../../rst/dev_guide/style_guide/index.rst:141
msgid "The Ansible documentation supports a range of `Pygments lexers <https://pygments.org/>`_ for `syntax highlighting <https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#code-examples>`_ to make our code examples look good. Each code-block must be correctly indented and surrounded by blank lines."
msgstr "Ansible ドキュメントは、コード例の見栄えを良くするため、`構文の強調表示 <https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#code-examples>`_ の `Pygments lexers <https://pygments.org/>`_ の範囲をサポートします。コードブロックは適切にインデントされ、空の行で囲む必要があります。"

#: ../../rst/dev_guide/style_guide/index.rst:144
msgid "The Ansible documentation allows the following values:"
msgstr "Ansible ドキュメントでは、以下の値を使用できます。"

#: ../../rst/dev_guide/style_guide/index.rst:146
msgid "none (no highlighting)"
msgstr "なし (強調表示なし)"

#: ../../rst/dev_guide/style_guide/index.rst:147
msgid "ansible-output (a custom lexer for Ansible output)"
msgstr "ansible-output (Ansible 出力用のカスタム lexer)"

#: ../../rst/dev_guide/style_guide/index.rst:148
msgid "bash"
msgstr "bash"

#: ../../rst/dev_guide/style_guide/index.rst:149
msgid "console"
msgstr "console"

#: ../../rst/dev_guide/style_guide/index.rst:150
msgid "csharp"
msgstr "csharp"

#: ../../rst/dev_guide/style_guide/index.rst:151
msgid "ini"
msgstr "ini"

#: ../../rst/dev_guide/style_guide/index.rst:153
msgid "powershell"
msgstr "powershell"

#: ../../rst/dev_guide/style_guide/index.rst:154
msgid "python"
msgstr "python"

#: ../../rst/dev_guide/style_guide/index.rst:155
msgid "rst"
msgstr "rst"

#: ../../rst/dev_guide/style_guide/index.rst:156
msgid "sh"
msgstr "sh"

#: ../../rst/dev_guide/style_guide/index.rst:157
msgid "shell"
msgstr "shell"

#: ../../rst/dev_guide/style_guide/index.rst:158
msgid "shell-session"
msgstr "shell-session"

#: ../../rst/dev_guide/style_guide/index.rst:159
msgid "text"
msgstr "text"

#: ../../rst/dev_guide/style_guide/index.rst:160
msgid "yaml"
msgstr "yaml"

#: ../../rst/dev_guide/style_guide/index.rst:161
msgid "yaml+jinja"
msgstr "yaml+jinja"

#: ../../rst/dev_guide/style_guide/index.rst:163
msgid "For example, you can highlight Python code using following syntax:"
msgstr "たとえば、以下の構文を使用して Python コードを強調表示できます。"

#: ../../rst/dev_guide/style_guide/index.rst:175
msgid "Internal navigation"
msgstr "内部ナビゲーション"

#: ../../rst/dev_guide/style_guide/index.rst:177
msgid "`Anchors (also called labels) and links <https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#ref-role>`_ work together to help users find related content. Local tables of contents also help users navigate quickly to the information they need. All internal links should use the ``:ref:`` syntax. Every page should have at least one anchor to support internal ``:ref:`` links. Long pages, or pages with multiple levels of headers, can also include a local TOC."
msgstr "`アンカー (ラベルとも呼ばれます) およびリンク <https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#ref-role>` は、関連コンテンツを見つけやすくするために、あるローカルテーブルも必要な情報に移動するのに役立ちます。すべての内部リンクで ``:ref:`` 構文を使用する必要があります。また、各ページには内部 ``:ref:`` リンクに対応するアンカーが 1 つ以上必要になります。長いページまたは複数のヘッダーレベルを持つページにも、ローカルの TOC を使用できます。"

#: ../../rst/dev_guide/style_guide/index.rst:186
msgid "Avoid raw URLs. RST and sphinx allow ::code:`https://my.example.com`, but this is unhelpful for those using screen readers. ``:ref:`` links automatically pick up the header from the anchor, but for external links, always use the ::code:`link title <link-url>`_` format."
msgstr "未処理の URL は使用しないでください。RST と sphinx では ::code:`https://my.example.com` が許可されますが、これはスクリーンリーダーを使用するユーザーにとっては役に立ちません。``:ref:`` リンクはアンカーからヘッダーを自動的に選択しますが、外部リンクの場合は常に ::code:`link title <link-url>`_` 形式を使用します。"

#: ../../rst/dev_guide/style_guide/index.rst:191
msgid "Adding anchors"
msgstr "アンカーの追加"

#: ../../rst/dev_guide/style_guide/index.rst:193
msgid "Include at least one anchor on every page"
msgstr "すべてのページに少なくとも 1 つのアンカーを含める。"

#: ../../rst/dev_guide/style_guide/index.rst:194
msgid "Place the main anchor above the main header"
msgstr "メインヘッダーの上にメインアンカーを配置する。"

#: ../../rst/dev_guide/style_guide/index.rst:195
msgid "If the file has a unique title, use that for the main page anchor::"
msgstr "このファイルに一意のタイトルがある場合は、メインページのアンカーに使用します。"

#: ../../rst/dev_guide/style_guide/index.rst:199
msgid "You may also add anchors elsewhere on the page"
msgstr "ページにアンカーを追加することもできます。"

#: ../../rst/dev_guide/style_guide/index.rst:202
msgid "Adding internal links"
msgstr "内部リンクの追加"

#: ../../rst/dev_guide/style_guide/index.rst:204
msgid "All internal links must use ``:ref:`` syntax. These links both point to the anchor defined above:"
msgstr "すべての内部リンクには ``:ref:`` 構文を使用する必要があります。これらのリンクは共に、上で定義したアンカーを指定します。"

#: ../../rst/dev_guide/style_guide/index.rst:211
msgid "The second example adds custom text for the link."
msgstr "2 つ目の例は、リンクのカスタムテキストを追加します。"

#: ../../rst/dev_guide/style_guide/index.rst:214
msgid "Adding links to modules and plugins"
msgstr "モジュールおよびプラグインへのリンクの追加"

#: ../../rst/dev_guide/style_guide/index.rst:216
msgid "Ansible 2.10 and later require the extended Fully Qualified Collection Name (FQCN) as part of the links:"
msgstr "Ansible 2.10 以降は、リンクの一部として、拡張された完全修飾コレクション名 (FQCN) が必要です。"

#: ../../rst/dev_guide/style_guide/index.rst:228
msgid "displays as :ref:`ansible.builtin.first_found lookup plugin <ansible_collections.ansible.builtin.first_found_lookup>`."
msgstr ":ref:`ansible.builtin.first_found lookup plugin <ansible_collections.ansible.builtin.first_found_lookup>` として表示します。"

#: ../../rst/dev_guide/style_guide/index.rst:230
msgid "Modules require different suffixes from other plugins:"
msgstr "モジュールには、他のプラグインとは異なるサフィックスが必要です。"

#: ../../rst/dev_guide/style_guide/index.rst:232
msgid "Module links use this extended FQCN module name with ``_module`` for the anchor."
msgstr "モジュールリンクでは、この広範な FQCN モジュール名に、アンカーに ``_module`` を使用します。"

#: ../../rst/dev_guide/style_guide/index.rst:233
msgid "Plugin links use this extended FQCN plugin name with the plugin type (``_connection`` for example)."
msgstr "プラグインのリンクは、この広範な FQCN プラグイン名をプラグインタイプ (``_connection`` など) で使用します。"

#: ../../rst/dev_guide/style_guide/index.rst:242
msgid "``ansible.builtin`` is the FQCN for modules included in ``ansible.base``. Documentation links are the only place you prepend ``ansible_collections`` to the FQCN. This is used by the documentation build scripts to correctly fetch documentation from collections on Ansible Galaxy."
msgstr "``ansible.builtin`` は、``ansible.base`` に含まれているモジュールの FQCN です。ドキュメントのリンクは、``ansible_collections`` を FQCN の前に付ける唯一の場所です。これは、Ansible Galaxy のコレクションからドキュメントを適切に取得するために、ドキュメントビルドスクリプトにより使用されます。"

#: ../../rst/dev_guide/style_guide/index.rst:247
msgid "Adding local TOCs"
msgstr "ページ内 (ローカル) 目次の追加"

#: ../../rst/dev_guide/style_guide/index.rst:249
msgid "The page you're reading includes a `local TOC <https://docutils.sourceforge.io/docs/ref/rst/directives.html#table-of-contents>`_. If you include a local TOC:"
msgstr "このページには `ローカル TOC <https://docutils.sourceforge.io/docs/ref/rst/directives.html#table-of-contents>`_ が含まれます。ローカルの TOC を追加する場合は、以下のようになります。"

#: ../../rst/dev_guide/style_guide/index.rst:252
msgid "place it below, not above, the main heading and (optionally) introductory text"
msgstr "目次の下に、主要な見出しと (任意で) 紹介文を追加します。目次の上には追加しないでください。"

#: ../../rst/dev_guide/style_guide/index.rst:253
msgid "use the ``:local:`` directive so the page's main header is not included"
msgstr "そのページの主要なヘッダーが含まれないように ``:local:`` ディレクティブを使用します。"

#: ../../rst/dev_guide/style_guide/index.rst:254
msgid "do not include a title"
msgstr "タイトルは除外します。"

#: ../../rst/dev_guide/style_guide/index.rst:256
msgid "The syntax is:"
msgstr "構文は以下のようになります。"

#: ../../rst/dev_guide/style_guide/index.rst:264
msgid "Accessibility guidelines"
msgstr "アクセシビリティのガイドライン"

#: ../../rst/dev_guide/style_guide/index.rst:266
msgid "Ansible documentation has a goal to be more accessible. Use the following guidelines to help us reach this goal."
msgstr "Ansible ドキュメントには、アクセスしやすくするという目標があります。次のガイドラインを使用することで、この目標を達成できます。"

#: ../../rst/dev_guide/style_guide/index.rst:276
msgid "Images and alternative text"
msgstr "イメージおよび代替テキスト"

#: ../../rst/dev_guide/style_guide/index.rst:269
msgid "Ensure all icons, images, diagrams, and non text elements have a meaningful alternative-text description. Do not include screen captures of CLI output. Use ``code-block`` instead."
msgstr "すべてのアイコン、イメージ、ダイアグラム、および非テキスト要素に意味のある代替テキストの説明があることを確認してください。CLI 出力のスクリーンキャプチャーは含めないでください。代わりに ``code-block`` を使用してください。"

#: ../../rst/dev_guide/style_guide/index.rst:279
msgid "Links and hypertext"
msgstr "リンクとハイパーテキスト"

#: ../../rst/dev_guide/style_guide/index.rst:279
msgid "URLs and cross-reference links have descriptive text that conveys information about the content of the linked target. See :ref:`style_links` for how to format links."
msgstr "URL と相互参照リンクには、リンク先のターゲットの内容に関する情報を伝える説明テキストがあります。リンクの形式については、:ref:`style_links` を参照してください。"

#: ../../rst/dev_guide/style_guide/index.rst:297
msgid "Tables"
msgstr "Tables"

#: ../../rst/dev_guide/style_guide/index.rst:282
msgid "Tables have a simple, logical reading order from left to right, and top to bottom. Tables include a header row and avoid empty or blank table cells. Label tables with a descriptive title."
msgstr "テーブルには、論理的な読み取り順序があり、左から右、上から下に読み取ります。テーブルにはヘッダー行が含まれ、空のテーブルセルや空白のテーブルセルを回避します。テーブルには説明的なタイトルをラベル付けします。"

#: ../../rst/dev_guide/style_guide/index.rst:303
msgid "Colors and other visual information"
msgstr "色やその他の視覚情報"

#: ../../rst/dev_guide/style_guide/index.rst:300
msgid "Avoid instructions that rely solely on sensory characteristics. For example, do not use ``Click the square, blue button to continue.``"
msgstr "感覚特性のみに依存する命令は回避します。たとえば、``Click the square, blue button to continue.`` は使用しないでください。"

#: ../../rst/dev_guide/style_guide/index.rst:301
msgid "Convey information by methods and not by color alone."
msgstr "色だけではなく、メソッドにより情報を伝えます。"

#: ../../rst/dev_guide/style_guide/index.rst:302
msgid "Ensure there is sufficient contrast between foreground and background text or graphical elements in images and diagrams."
msgstr "イメージや図の全景と背景のテキストやグラフィック要素の間に、十分なコントラストがあることを確認します。"

#: ../../rst/dev_guide/style_guide/index.rst:303
msgid "Instructions for navigating through an interface make sense without directional indicators such as left, right, above, and below."
msgstr "インターフェイス上を移動する順序は、左、右、上、下などの方向インジケーターがなくても理解できます。"

#: ../../rst/dev_guide/style_guide/index.rst:306
msgid "Accessibility resources"
msgstr "アクセシビリティーリソース"

#: ../../rst/dev_guide/style_guide/index.rst:308
msgid "Use the following resources to help test your documentation changes:"
msgstr "以下のリソースを使用して、ドキュメントの変更をテストします。"

#: ../../rst/dev_guide/style_guide/index.rst:310
msgid "`axe DevTools browser extension <https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US&_ga=2.98933278.1490638154.1645821120-953800914.1645821120>`_ - Highlights accessibility issues on a website page."
msgstr "`axe DevTools browser extension <https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US&_ga=2.98933278.1490638154.1645821120-953800914.1645821120>`_ - Web サイトのページ上でアクセシビリティーの問題を強調表示します。"

#: ../../rst/dev_guide/style_guide/index.rst:311
msgid "`WAVE browser extension <https://wave.webaim.org/extension/>`_ from WebAIM  - another accessibility tester."
msgstr "WebAIM からの `WAVE browser extension <https://wave.webaim.org/extension/>`_ - 別のアクセシビリティーテスター。"

#: ../../rst/dev_guide/style_guide/index.rst:312
msgid "`Orca screen reader <https://help.gnome.org/users/orca/stable/>`_ - Common tool used by people with vision impairments."
msgstr "`Orca screen reader <https://help.gnome.org/users/orca/stable/>`_ - 視覚障害を持つユーザーが使用する一般的なツール。"

#: ../../rst/dev_guide/style_guide/index.rst:313
msgid "`color filter <https://www.toptal.com/designers/colorfilter/>`_ - For color-blind testing."
msgstr "`color filter <https://www.toptal.com/designers/colorfilter/>`_ - 色覚検査用。"

#: ../../rst/dev_guide/style_guide/index.rst:316
msgid "More resources"
msgstr "参考資料"

#: ../../rst/dev_guide/style_guide/index.rst:318
msgid "These pages offer more help with grammatical, stylistic, and technical rules for documentation."
msgstr "以下のページでは、ドキュメントに関する文法、スタイル、および技術的なルールを紹介しています。"

#: ../../rst/dev_guide/style_guide/index.rst:333
msgid ":ref:`community_documentation_contributions`"
msgstr ":ref:`community_documentation_contributions`"

#: ../../rst/dev_guide/style_guide/index.rst:334
msgid "How to contribute to the Ansible documentation"
msgstr "Ansible ドキュメントへの貢献方法"

#: ../../rst/dev_guide/style_guide/index.rst:335
msgid ":ref:`testing_documentation_locally`"
msgstr ":ref:`testing_documentation_locally`"

#: ../../rst/dev_guide/style_guide/index.rst:336
msgid "How to build the Ansible documentation"
msgstr "Ansible ドキュメントのビルド方法"

#: ../../rst/dev_guide/style_guide/index.rst:338
msgid "#ansible-docs IRC chat channel"
msgstr "IRC チャットチャンネル (#ansible-docs)"

#: ../../rst/dev_guide/style_guide/resources.rst:2
msgid "Resources"
msgstr "リソース"

#: ../../rst/dev_guide/style_guide/resources.rst:3
msgid "Follow the style of the :ref:`Ansible Documentation<ansible_documentation>`"
msgstr ":ref:`Ansible ドキュメント<ansible_documentation>` のスタイルに従ってください。"

#: ../../rst/dev_guide/style_guide/resources.rst:4
msgid "Ask for advice 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でMatrixを使用、または`irc.libera.chat <https://libera.chat/>`_でIRCを使用）。"

#: ../../rst/dev_guide/style_guide/resources.rst:5
msgid "Review these online style guides:"
msgstr "オンラインで利用できるスタイルガイドを参照してください。"

#: ../../rst/dev_guide/style_guide/resources.rst:7
msgid "`AP Stylebook <https://www.apstylebook.com>`_"
msgstr "`AP Stylebook <https://www.apstylebook.com>`_"

#: ../../rst/dev_guide/style_guide/resources.rst:8
msgid "`Chicago Manual of Style <https://www.chicagomanualofstyle.org/home.html>`_"
msgstr "`Chicago Manual of Style <https://www.chicagomanualofstyle.org/home.html>`_"

#: ../../rst/dev_guide/style_guide/resources.rst:9
msgid "`Strunk and White's Elements of Style <https://www.crockford.com/wrrrld/style.html>`_"
msgstr "`Strunk and White's Elements of Style <https://www.crockford.com/wrrrld/style.html>`_"

#: ../../rst/dev_guide/style_guide/resources.rst:10
msgid "`Google developer documentation style guide <https://developers.google.com/style/highlights>`_"
msgstr "`Google developer documentation style guide <https://developers.google.com/style/highlights>`_"

#: ../../rst/dev_guide/style_guide/search_hints.rst:5
msgid "Writing documentation so search can find it"
msgstr "検索用のドキュメントの作成"

#: ../../rst/dev_guide/style_guide/search_hints.rst:7
msgid "One of the keys to writing good documentation is to make it findable. Readers use a combination of internal site search and external search engines such as Google or duckduckgo."
msgstr "優れたドキュメントを作成するための鍵の 1 つは、ドキュメントを見つけやすくすることです。読者は、サイト内検索や、Google、duckduckgo などの外部検索エンジンを組み合わせて使用します。"

#: ../../rst/dev_guide/style_guide/search_hints.rst:9
msgid "To ensure Ansible documentation is findable, you should:"
msgstr "Ansible ドキュメントが見つかるようにするには、以下を行う必要があります。"

#: ../../rst/dev_guide/style_guide/search_hints.rst:11
msgid "Use headings that clearly reflect what you are documenting."
msgstr "ドキュメントの内容を明確に反映させる見出しを使用します。"

#: ../../rst/dev_guide/style_guide/search_hints.rst:12
msgid "Use numbered lists for procedures or high-level steps where possible."
msgstr "可能な場合は、番号付きの一覧または手順の概要手順に使用します。"

#: ../../rst/dev_guide/style_guide/search_hints.rst:13
msgid "Avoid linking to github blobs where possible."
msgstr "可能な限り、github ブログにはリンクしないでください。"

#: ../../rst/dev_guide/style_guide/search_hints.rst:17
msgid "Using clear headings in documentation"
msgstr "ドキュメントで明確な見出しの使用"

#: ../../rst/dev_guide/style_guide/search_hints.rst:19
msgid "We all use simple English when we want to find something. For example, the title of this page could have been any one of the following:"
msgstr "何かを探すときは、簡単な英語を使います。たとえば、このページのタイトルは次のいずれかになります。"

#: ../../rst/dev_guide/style_guide/search_hints.rst:21
msgid "Search optimization"
msgstr "Search optimization (検索の最適化)"

#: ../../rst/dev_guide/style_guide/search_hints.rst:22
msgid "Findable documentation"
msgstr "Findable documentation (検索可能なドキュメント)"

#: ../../rst/dev_guide/style_guide/search_hints.rst:23
msgid "Writing for findability"
msgstr "Writing for findability (見やすくするための記述)"

#: ../../rst/dev_guide/style_guide/search_hints.rst:25
msgid "What we are really trying to describe is - how do I write documentation so search engines can find my content? That simple phrase is what drove the title of this section. When you are creating your headings for documentation, spend some time to think about what you would type in a search box to find it, or more importantly, how someone less familiar with Ansible would try to find that information. Your heading should be the answer to that question."
msgstr "ここで説明しようとしているのは、「検索エンジンがコンテンツを見つけられるようにするドキュメントの書き方」です。その単純なフレーズが、このセクションのタイトルになりました。ドキュメントの見出しを作成するときは、検索ボックスに何を入力して検索するのか、さらに重要なことに、Ansible にあまり詳しくないユーザーがその情報をどのように見つけようとするかを考える時間を設けてください。見出しは、その質問に対する答えであるべきです。"

#: ../../rst/dev_guide/style_guide/search_hints.rst:27
msgid "One word of caution - you do want to limit the size of your headings. A full heading such as `How do I write documentation so search engines can find my content?` is too long. Search engines would truncate anything over 50 - 60 characters. Long headings would also wrap on smaller devices such as a smart phone."
msgstr "注記 - 見出しのサイズを制限する場合は、`How do I write documentation so search engines can find my content?` などの見出しにすると長すぎます。検索エンジンは 50 ~ 60 文字を超えるものは切り捨てます。長い見出しも、スマートフォンなどの小規模なデバイスでは折り返されます。"

#: ../../rst/dev_guide/style_guide/search_hints.rst:30
msgid "Using numbered lists for `zero position` snippets"
msgstr "`zero position` スニペットの番号付きのリストの使用"

#: ../../rst/dev_guide/style_guide/search_hints.rst:32
msgid "Google can optimize the search results by adding a `feature snippet <https://support.google.com/websearch/answer/9351707>`_ at the top of the search results. This snippet provides a small window into the documentation on that first search result that adds more detail than the rest of the search results, and can occasionally answer the reader's questions right there, or at least verify that the linked page is what the reader is looking for."
msgstr "Google は、検索結果の上部に `機能スニペット <https://support.google.com/websearch/answer/9351707>`_ を追加して検索結果を最適化できます。このスニペットは、最初の検索結果に関するドキュメントに小さなウィンドウを提供し、残りの検索結果よりも詳細を追加し、時には読者の質問にその場で答えたり、少なくともリンク先のページが読者の探しているものであることを確認することができます。"

#: ../../rst/dev_guide/style_guide/search_hints.rst:34
msgid "Google returns the feature snippet in the form of numbered steps. Where possible, you should add a numbered list near the top of your documentation page, where appropriate. The steps can be the exact procedure a reader would follow, or could be a high level introduction to the documentation topic, such as the numbered list at the top of this page."
msgstr "Google は番号付きの手順の機能スニペットを返します。可能であれば、必要に応じて、ドキュメントページの上部付近に番号付きリストを追加する必要があります。手順は、読者が従う正確な手順にすることも、このページの上部にある番号付きリストなど、ドキュメントトピックの概要を説明することもできます。"

#: ../../rst/dev_guide/style_guide/search_hints.rst:37
msgid "Problems with github blobs on search results"
msgstr "検索結果に関する github ブロブの問題"

#: ../../rst/dev_guide/style_guide/search_hints.rst:39
msgid "Search engines do not typically return github blobs in search results, at least not in higher ranked positions. While it is possible and sometimes necessary to link to github blobs from documentation, the better approach would be to copy that information into an .rst page in Ansible documentation."
msgstr "検索エンジンは通常、少なくとも上位の位置では、検索結果に github ブロブを返しません。ドキュメントから github ブロブにリンクすることは可能であり、場合によっては必要ですが、より良いアプローチは、その情報を Ansible ドキュメントの .rst ページにコピーすることです。"

#: ../../rst/dev_guide/style_guide/search_hints.rst:42
msgid "Other search hints"
msgstr "他の検索ヒント"

#: ../../rst/dev_guide/style_guide/search_hints.rst:44
msgid "While it may not be possible to adapt your documentation to all search optimizations, keep the following in mind as you write your documentation:"
msgstr "すべての検索最適化にドキュメントを調整することができない場合もありますが、ドキュメントを作成する場合は、以下の点に留意してください。"

#: ../../rst/dev_guide/style_guide/search_hints.rst:46
msgid "**Search engines don't parse beyond the `#` in an html page.** So for example, all the subheadings on this page are appended to the main page URL. As such, when I search for 'Using number lists for zero position snippets', the search result would be a link to the top of this page, not a link directly to the subheading I searched for. Using :ref:`local TOCs <local_toc>` helps alleviate this problem as the reader can scan for the header at top of the page and click to the section they are looking for. For critical documentation, consider creating a new page that can be a direct search result page."
msgstr "**検索エンジンは、html ページ内の `#` 以降は解析しません。** そのため、たとえば、このページのすべての小見出しは、メインページの URL に付加されています。そのため、「Using number lists for zero position snippets」と検索すると、検索結果はこのページの冒頭へのリンクになり、検索した小見出しへの直接のリンクにはなりません。:ref:`ローカル TOC <local_toc>` を使用すると、読者がページに上部のヘッダーに目を通して、探しているセクションをクリックできるため、この問題を軽減することができます。重要な文書については、検索結果のページに直接アクセスできるように新しいページを作成することを検討してください。"

#: ../../rst/dev_guide/style_guide/search_hints.rst:48
msgid "**Make your first few sentences clearly describe your page topic.** Search engines return not just the URL, but a short description of the information at the URL. For Ansible documentation, we do not have description metadata embedded on each page. Instead, the search engines return the first couple of sentences (140 characters) on the page. That makes your first sentence or two very important to the reader who is searching for something in Ansible."
msgstr "**最初の 2、3 文でページのトピックを明確に説明してください。** 検索エンジンは URL だけでなく、その URL にある情報の簡単な説明も返します。Ansible ドキュメントの場合は、各ページに説明メタデータが埋め込まれていません。その代わり、検索エンジンはページの最初の 2、3 文 (140 文字) を返します。そのため、Ansibleで何かを検索している読者にとって、最初の 1〜2 文が非常に重要になります。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:2
msgid "Spelling - Word Usage - Common Words and Phrases to Use and Avoid"
msgstr "スペル、単語の使用、および使用または回避する一般的な単語とフレーズ"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:5
msgid "Acronyms"
msgstr "略語"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:7
msgid "Always uppercase. An acronym is a word formed from the initial letters of a name, such as ROM for Read-only memory, SaaS for Software as a Service, or by combining initial letters or part of a series of words, such as LILO for LInux LOader."
msgstr "常に大文字です。頭字語とは、ROM (Read-Only Memory) や SaaS (Software as a Service) のように名前の頭文字から形成された単語や、LILO (LInux LOader) のように一連の単語の頭文字や一部を組み合わせて形成された単語のことです。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:11
msgid "Spell out the acronym before using it in alone text, such as \"The Embedded DevKit (EDK)...\""
msgstr "略語は、単独で使用する前に、「The Embedded devkit (EDK)...」のように文字を略さずに書いて使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:14
msgid "Applications"
msgstr "アプリケーション"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:15
msgid "When used as a proper name, use the capitalization of the product, such as GNUPro or Source-Navigator. When used as a command, use lowercase as appropriate, such as \"To start GCC, type ``gcc``.\""
msgstr "固有名詞として使用する場合は、GNUPro または Source-Navigator のように製品の大文字を使用します。コマンドとして使用する場合は、「To start GCC, type ``gcc``.」(GCC を起動する場合は、``gcc`` を入力します) のように、適切な小文字を使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:19
msgid "\"vi\" is always lowercase."
msgstr "「vi」は常に小文字です。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:22
msgid "As"
msgstr "As"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:23
msgid "This is often used to mean \"because\", but has other connotations, for example, parallel or simultaneous actions. If you mean \"because\", say \"because\"."
msgstr "原因を示す場合によく使用されますが、並列または同時の操作など、他の意味もあります。「原因」を意味する場合は、「because」を使用してください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:26
msgid "Asks for"
msgstr "Asks for"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:27
msgid "Use \"requests\" instead."
msgstr "代わりに「requests」を使用してください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:30
msgid "Assure/Ensure/Insure"
msgstr "Assure/Ensure/Insure"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:31
msgid "Assure implies a sort of mental comfort. As in \"I assured my husband that I would eventually bring home beer.\""
msgstr "「assure」は、一種の精神的な安心さを意味します。たとえば、「I assured my husband that I would eventually bring home beer. (私は夫に最終的に家のビールを持ってくることを約束しました)」のように使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:33
msgid "Ensure means \"to make sure.\""
msgstr "「ensure」は、「確実に」を意味します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:35
msgid "Insure relates to monetary insurance."
msgstr "「insure」は、金銭的な保険に関係があります。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:39
msgid "Back up"
msgstr "Back up"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:40
msgid "This is a verb. You \"back up\" files; you do not \"backup\" files."
msgstr "これは動詞です。ファイルを「バックアップ」するときは、「backup」ではなく、「back up」と記載します (You back up files)。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:43
msgid "Backup"
msgstr "Backup"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:44
msgid "This is a noun. You create \"backup\" files; you do not create \"back up\" files."
msgstr "これは名詞です。「バックアップ」ファイルを作成するときは、「back up」ではなく、「backup」と記載します (You create backup files)。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:47
msgid "Backward"
msgstr "Backward"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:48
msgid "Correct. Avoid using backwards unless you are stating that something has \"backwards compatibility.\""
msgstr "適切です。「backwards compatibility」(後方互換性) 以外の説明に、「backward」という単語を使用しないでください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:51
msgid "Backwards compatibility"
msgstr "Backwards compatibility"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:52
msgid "Correct as is."
msgstr "そのまま使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:55
msgid "By way of"
msgstr "By way of"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:56
msgid "Use \"using\" instead."
msgstr "代わりに「using」を使用してください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:59
msgid "Can/May"
msgstr "Can/May"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:60
msgid "Use \"can\" to describe actions or conditions that are possible. Use \"may\" only to describe situations where permission is being given. If either \"can,\" \"could,\" or \"may\" apply, use \"can\" because it's less tentative."
msgstr "「can」は、可能な操作や条件を説明するのに使用します。許可が必要な状況を説明するには、「may」を使用します。「can」、「could」、または「may」のいずれかが当てはまる場合は、「can」を使用します (暫定的な意味合いが少ないため)。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:63
msgid "CD or cd"
msgstr "CD または cd"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:64
msgid "When referring to a compact disk, use CD, such as \"Insert the CD into the CD-ROM drive.\" When referring to the change directory command, use cd."
msgstr "コンパクトディスクを参照する場合は、CD を使用します。たとえば、「Insert the CD into the CD-ROM drive.」(CD を CD-ROM ドライブに挿入します。) とします。ディレクトリーを変更する change directory コマンドを示す場合は、cd を使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:67
msgid "CD-ROM"
msgstr "CD-ROM"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:68
msgid "Correct. Do not use \"cdrom,\" \"CD-Rom,\" \"CDROM,\" \"cd-rom\" or any other variation. When referring to the drive, use CD-ROM drive, such as \"Insert the CD into the CD-ROM drive.\" The plural is \"CD-ROMs.\""
msgstr "「cdrom」、「CD-Rom」、「CDROM」、「cd-rom」などの表記は使用しないでください。ドライブを参照する場合は、「Insert the CD into the CD-ROM drive (CD-ROM ドライブなど)」のように「CD-ROM drive」を使用します。複数形は「CD-ROMs」となります。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:72
msgid "Command line"
msgstr "Command line"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:73
msgid "Correct. Do not use \"command-line\" or \"commandline\" as a noun. If used as an adjective, \"command-line\" is appropriate, for example \"command-line arguments\"."
msgstr "適切です。「command-line」または「commandline」を名詞として使用しないでください。形容詞として使用する場合は、「command-line arguments」のように、「command-line」が適切です。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:75
msgid "Use \"command line\" to describes where to place options for a command, but not where to type the command. Use \"shell prompt\" instead to describe where to type commands. The line on the display screen where a command is expected. Generally, the command line is the line that contains the most recently displayed command prompt."
msgstr "「コマンドライン」を使用して、コマンドのオプションを追加する場所を記述しますが、コマンドを入力する場所は記述しません。コマンドを入力する場所を説明する場合は、代わりに「shell prompt」を使用します。コマンドが期待される画面上の行となります。通常、コマンドラインは、最後に表示されるコマンドプロンプトを含む行となります。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:79
msgid "Daylight saving time (DST)"
msgstr "Daylight saving time (DST)"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:81
msgid "Correct. Do not use daylight savings time. Daylight Saving Time (DST) is often misspelled \"Daylight Savings\", with an \"s\" at the end. Other common variations are \"Summer Time\"and \"Daylight-Saving Time\". (https://www.timeanddate.com/time/dst/daylight-savings-time.html)"
msgstr "適切です。「daylight savings time」は使用しないでください。「Daylight Saving Time (DST)」は、「Daylight Savings」のように、最後に s が付いている場合がありますが、これは間違いです。その他の一般的な表記法には、「Summer Time」および「Daylight-Saving Time」があります (https://www.timeanddate.com/time/dst/daylight-savings-time.html)。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:85
msgid "Download"
msgstr "Download"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:86
msgid "Correct. Do not use \"down load\" or \"down-load.\""
msgstr "適切です。「down load」または「down-load」は使用しないでください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:90
msgid "Spell it out: \"For example.\""
msgstr "省略せずに「For example」とします。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:93
msgid "Failover"
msgstr "Failover"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:94
msgid "When used as a noun, a failover is a backup operation that automatically switches to a standby database, server or network if the primary system fails or is temporarily shut down for servicing. Failover is an important fault tolerance function of mission-critical systems that rely on constant accessibility. Failover automatically and transparently to the user redirects requests from the failed or down system to the backup system that mimics the operations of the primary system."
msgstr "名詞として使用される場合、フェイルオーバーとは、プライマリーシステムに障害が発生したり、サービスのために一時的に停止した場合に、自動的にスタンバイデータベース、サーバー、またはネットワークに切り替えるバックアップ操作のことです。フェイルオーバーは、常にアクセス可能であることが求められるミッションクリティカルなシステムの重要なフォールトトレランス機能となります。フェイルオーバーは、自動的かつユーザーに透過的に、障害や停止したシステムからのリクエストを、プライマリーシステムの操作を模倣したバックアップシステムにリダイレクトします。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:97
msgid "Fail over"
msgstr "Fail over"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:98
msgid "When used as a verb, fail over is two words since there can be different tenses such as failed over."
msgstr "動詞として使用する場合は、時制を変えられるように (failed over など)、2 つの単語にします。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:101
msgid "Fewer"
msgstr "Fewer"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:102
msgid "Fewer is used with plural nouns. Think things you could count.  Time, money, distance, and weight are often listed as exceptions to the traditional \"can you count it\" rule, often thought of a singular amounts (the work will take less than 5 hours, for example)."
msgstr "fewer は、複数形の名詞で使用します。数を数えることができるものに使用します。時間、お金、距離、および重量は、従来の「数えることができるか」ルールの例外として挙げられることが多く、通常は 1 つの量と見なされます。たとえば、「the work will take less than 5 hours」(作業にかかる時間は 5 時間未満です)。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:105
msgid "File name"
msgstr "File name"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:106
msgid "Correct. Do not use \"filename.\""
msgstr "適切です。「filename」は使用しないでください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:109
msgid "File system"
msgstr "File system"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:110
msgid "Correct. Do not use \"filesystem.\" The system that an operating system or program uses to organize and keep track of files. For example, a hierarchical file system is one that uses directories to organize files into a tree structure. Although the operating system provides its own file management system, you can buy separate file management systems. These systems interact smoothly with the operating system but provide more features, such as improved backup procedures and stricter file protection."
msgstr "適切です。「filesystem」は使用しないでください。オペレーティングシステムまたはプログラムがファイルを整理し、追跡するために使用するシステムです。たとえば、階層ファイルシステムは、ディレクトリーを使用してファイルをツリー構造に編成するものです。オペレーティングシステムは独自のファイル管理システムを提供していますが、別のファイル管理システムを使用することもできます。このようなシステムはオペレーティングシステムとスムーズに対話しますが、バックアップ手順の改善やファイル保護の強化など、より多くの機能を提供します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:113
msgid "For instance"
msgstr "For instance"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:114
msgid "For example,\" instead."
msgstr "代わりに「For example」を使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:117
msgid "For further/additional/whatever information"
msgstr "For further/additional/whatever information"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:118
msgid "Use \"For more information\""
msgstr "「For more information」を使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:121
msgid "For this reason"
msgstr "For this reason"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:122
msgid "Use \"therefore\"."
msgstr "「therefore」を使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:125
msgid "Forward"
msgstr "Forward"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:126
msgid "Correct. Avoid using \"forwards.\""
msgstr "適切です。「forwards」は使用しないでください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:129
msgid "Gigabyte (GB)"
msgstr "Gigabyte (GB)"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:130
msgid "2 to the 30th power (1,073,741,824) bytes. One gigabyte is equal to 1,024 megabytes. Gigabyte is often abbreviated as G or GB."
msgstr "2 の 30乗 (1,073,741,824) バイト。1 ギガバイトは 1,024 メガバイトに相当します。ギガバイトは、G または GB と略されることがよくあります。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:133
msgid "Got"
msgstr "Got"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:134
#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:208
msgid "Avoid. Use \"must\" instead."
msgstr "使用しないようにしてください。代わりに \"must\" を使用してください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:137
msgid "High-availability"
msgstr "High-availability"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:138
msgid "Correct. Do not use \"high availability.\""
msgstr "適切です。「hight availability」は使用しないでください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:141
msgid "Highly available"
msgstr "Highly available"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:142
msgid "Correct. Do not use highly-available.\""
msgstr "適切です。高可用性は使用しないでください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:145
msgid "Hostname"
msgstr "Hostname"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:146
msgid "Correct. Do not use host name."
msgstr "適切です。ホスト名は使用しないでください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:149
msgid "i.e."
msgstr "i.e."

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:150
msgid "Spell it out: \"That is.\""
msgstr "「That is」を使用してください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:153
msgid "Installer"
msgstr "Installer"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:154
msgid "Avoid. Use \"installation program\" instead."
msgstr "使用しないでください。代わりに「installation program」を使用してください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:157
msgid "It's and its"
msgstr "It's および its"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:158
msgid "\"It's\" is a contraction for \"it is;\" use \"it is\" instead of \"it's.\" Use \"its\" as a possessive pronoun (for example, \"the store is known for its low prices\")."
msgstr "「It's」は「it is」の短縮形です。「it's」ではなく「it is」を使用します。所有代名詞は「its」と使用します。たとえば「the store is known for its low prices」(この店は低価格で知られています) となります。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:161
msgid "Less"
msgstr "Less"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:162
msgid "Less is used with singular nouns. For example \"View less details\" wouldn't be correct but \"View less detail\" works. Use fewer when you have plural nouns (things you can count)."
msgstr "Less は単数名詞で使用されます。たとえば、「View less details」は間違っていますが、「View less detail」は適切です。複数名詞 (数えられる物) には、「fewer」を使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:165
msgid "Linux"
msgstr "Linux"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:166
msgid "Correct. Do not use \"LINUX\" or \"linux\" unless referring to a command, such as \"To start Linux, type linux.\" Linux is a registered trademark of Linus Torvalds."
msgstr "適切です。コマンドを参照している場合 (たとえば「To start Linux, type linux」(Linux を起動する場合は、linux と入力します)) を除き、「LINUX」または「linux」を使用しないでください。Linux は、Linus Torvalds の登録商標です。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:169
msgid "Login"
msgstr "Login"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:170
msgid "A noun used to refer to the login prompt, such as \"At the login prompt, enter your username.\""
msgstr "ログインプロンプトを示すために使用している名詞です。たとえば、「At the login prompt, enter your username.」(ログインプロンプトでユーザー名を入力してください。) とします。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:173
msgid "Log in"
msgstr "Log in"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:174
msgid "A verb used to refer to the act of logging in. Do not use \"login,\" \"loggin,\" \"logon,\" and other variants. For example, \"When starting your computer, you are requested to log in...\""
msgstr "ログインの動作を参照するために使用される動詞です。「login」、「loggin」、「loggin」などの形は使用しないでください。たとえば、「When starting your computer, you are requested to log in...」(コンピューターを起動すると、ログインを要求されます...) と表示されます。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:177
msgid "Log on"
msgstr "Log on"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:178
msgid "To make a computer system or network recognize you so that you can begin a computer session. Most personal computers have no log-on procedure -- you just turn the machine on and begin working. For larger systems and networks, however, you usually need to enter a username and password before the computer system will allow you to execute programs."
msgstr "コンピューターセッションを開始できるように、コンピューターシステムまたはネットワークにユーザーを認識させることです。ほとんどのコンピューターにはログオン手順がありません。マシンの電源を入れれば動くためです。ただし、大規模システムやネットワークの場合には、通常、コンピュータシステムでプログラムを実行する前に、ユーザー名とパスワードを入力する必要があります。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:181
msgid "Lots of"
msgstr "Lots of"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:182
msgid "Use \"Several\" or something equivalent instead."
msgstr "代わりに「several」などの単語を使用してください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:185
msgid "Make sure"
msgstr "Make sure"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:186
msgid "This means \"be careful to remember, attend to, or find out something.\" For example, \"...make sure that the rhedk group is listed in the output.\" Try to use verify or ensure instead."
msgstr "これは、「何かを覚えたり、注意したり、見つけたりするように注意する」という意味です。たとえば、「...make sure that the rhedk group is listed in the output.」(rhedk グループが出力の一覧に含まれていることを確認してください) となります。代わりに verify や ensure を使用してください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:190
msgid "Manual/man page"
msgstr "Manual/man page"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:191
msgid "Correct. Two words. Do not use \"manpage\""
msgstr "適切です。2 つの単語になります。「manpage」は使用しないでください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:194
msgid "MB"
msgstr "MB"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:195
msgid "When spelled MB, short for megabyte (1,000,000 or 1,048,576 bytes, depending on the context)."
msgstr "MB は、メガバイト (状況に応じて 1,000,000 バイトまたは 1,048,576 バイト) の略語です。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:196
msgid "When spelled Mb, short for megabit."
msgstr "Mb は、メガビットの略語です。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:199
msgid "MBps"
msgstr "MBps"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:200
msgid "Short for megabytes per second, a measure of data transfer speed. Mass storage devices are generally measured in MBps."
msgstr "1 秒あたりのメガバイトの略語で、データ転送速度の測定単位です。通常、大容量ストレージデバイスは、MBps で表されます。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:203
msgid "MySQL"
msgstr "MySQL"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:204
msgid "Common open source database server and client package. Do not use \"MYSQL\" or \"mySQL.\""
msgstr "一般的なオープンソースデータベースサーバーおよびクライアントパッケージです。「MYSQL」または「mySQL」は使用しないでください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:207
msgid "Need to"
msgstr "Need to"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:211
msgid "Read-only"
msgstr "Read-only"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:212
msgid "Correct. Use when referring to the access permissions of files or directories."
msgstr "適切です。ファイルまたはディレクトリーのアクセスパーミッションを参照する場合に使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:215
msgid "Real time/real-time"
msgstr "Real time/real-time"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:216
msgid "Depends. If used as a noun, it is the actual time during which something takes place. For example, \"The computer may partly analyze the data in real time (as it comes in) -- R. H. March.\" If used as an adjective, \"real-time\" is appropriate. For example, \"XEmacs is a self-documenting, customizable, extensible, real-time display editor.\""
msgstr "状況によって異なります。名詞として使用する場合は、それは何かが行われる実際の時間になります。たとえば、「The computer may partly analyze the data in real time (as it comes in) -- R. H. March」(コンピューターはデータをリアルタイムで部分的に分析する場合があります。(R. H.マーチ)) となります。形容詞として使用する場合は、「real-time」が適切です。たとえば、「XEmacs is a self-documenting, customizable, extensible, real-time display editor.」(XEmacs は、自己文書化を行う、カスタマイズ可能で、拡張可能な、リアルタイムディスプレイエディターです) となります。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:219
msgid "Refer to"
msgstr "Refer to"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:220
msgid "Use to indicate a reference (within a manual or website) or a cross-reference (to another manual or documentation source)."
msgstr "参照 (マニュアルまたは Web サイト内) または相互参照 (別のマニュアルまたはドキュメントソース) を示すために使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:223
msgid "See"
msgstr "See"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:224
msgid "Don't use. Use \"Refer to\" instead."
msgstr "使用しないでください。代わりに「Refer to」を使用してください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:227
msgid "Since"
msgstr "Since"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:228
msgid "This is often used to mean \"because\", but \"since\" has connotations of time, so be careful. If you mean \"because\", say \"because\"."
msgstr "この単語は「原因」を意味するためによく使用されますが、「since」には時間の意味合いがあるため、注意してください。「原因」を意味する場合は、「because」を使用してください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:231
msgid "Tells"
msgstr "Tells"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:232
msgid "Use \"Instructs\" instead."
msgstr "代わりに「instructs」を使用してください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:235
msgid "That/which"
msgstr "That/which"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:236
msgid "\"That\" introduces a restrictive clause-a clause that must be there for the sentence to make sense. A restrictive clause often defines the noun or phrase preceding it. \"Which\" introduces a non-restrictive, parenthetical clause-a clause that could be omitted without affecting the meaning of the sentence. For example: The car was travelling at a speed that would endanger lives. The car, which was traveling at a speed that would endanger lives, swerved onto the sidewalk. Use \"who\" or \"whom,\" rather than \"that\" or \"which,\" when referring to a person."
msgstr "「That」は、制限的関係詞節を導入します。これは、文が意味をなすために必要な節です。制限的関係詞節は、多くの場合、その前にある名詞または句を定義します。「Which」は、非制限の、括弧で囲まれた節を導入します。つまり、文の意味に影響を与えずに省略することができる節です。たとえば、「The car was travelling at a speed that would endanger lives.」(人命を危険にさらす速度で車が走行していました。) と、「The car, which was traveling at a speed that would endanger lives, swerved onto the sidewalk.」(人命を危険にさらす速度で走行していた車が歩道にのり上げました) です。人を指す場合は、「that」または「which」ではなく「who」または「whom」を使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:239
msgid "Then/than"
msgstr "Then/than"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:240
msgid "\"Then\" refers to a time in the past or the next step in a sequence. \"Than\" is used for comparisons."
msgstr "「then」は、ひと続きのものの中から、シーケンスの過去のステップまたは次のステップの時間を指します。比較には「than」が使用されます。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:245
msgid "Third-party"
msgstr "Third-party"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:246
msgid "Correct. Do not use \"third party\"."
msgstr "適切です。「third party」は使用しないでください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:249
msgid "Troubleshoot"
msgstr "Troubleshoot"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:250
msgid "Correct. Do not use \"trouble shoot\" or \"trouble-shoot.\" To isolate the source of a problem and fix it. In the case of computer systems, the term troubleshoot is usually used when the problem is suspected to be hardware -related. If the problem is known to be in software, the term debug is more commonly used."
msgstr "適切です。「trouble shoot」または「trouble-shoot」は使用しないでください。問題の原因を特定して修正するためのものです。コンピューターシステムの場合は、通常、問題がハードウェアに関連するものと考えられる場合に使用されます。問題がソフトウェアにあることが分かっている場合に、より一般的に使用されるのは「debug」です。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:253
msgid "UK"
msgstr "UK"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:254
#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:266
msgid "Correct as is, no periods."
msgstr "このとおりに使用します。ピリオドは付けません。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:257
msgid "UNIX®"
msgstr "UNIX®"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:258
msgid "Correct. Do not use \"Unix\" or \"unix.\" UNIX® is a registered trademark of The Open Group."
msgstr "適切です。「Unix」または「unix」は使用しないでください。UNIX® は、The Open Group の登録商標です。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:261
msgid "Unset"
msgstr "Unset"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:262
msgid "Don't use. Use Clear."
msgstr "使用しないでください。「Clear」を使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:265
msgid "US"
msgstr "US"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:269
msgid "User"
msgstr "User"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:270
msgid "When referring to the reader, use \"you\" instead of \"user.\" For example, \"The user must...\" is incorrect. Use \"You must...\" instead. If referring to more than one user, calling the collection \"users\" is acceptable, such as \"Other users may wish to access your database.\""
msgstr "読み手を示す場合は、「user」ではなく「you」を使用します。たとえば、「The user must...」は正しくありません。代わりに「You must...」を使用してください。複数のユーザーを示す場合は、「users」を使用できます。たとえば、「Other users may to access your database.」(その他のユーザーがデータベースにアクセスすることを望む可能性があります) です。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:273
msgid "Username"
msgstr "Username"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:274
msgid "Correct. Do not use \"user name.\""
msgstr "適切です。「user name」は使用しないでください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:277
msgid "View"
msgstr "View"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:278
msgid "When using as a reference (\"View the documentation available online.\"), do not use View. Use \"Refer to\" instead."
msgstr "参照として使用する場合、たとえば「View the documentation available online.」(オンラインで使用可能なドキュメントを参照してください) とする場合は、「view」を使用しないでください。代わりに「refer to」を使用してください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:281
msgid "Within"
msgstr "Within"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:282
msgid "Don't use to refer to a file that exists in a directory. Use \"In\"."
msgstr "ディレクトリーにあるファイルを参照する場合は使用しないでください。「In」を使用してください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:285
msgid "World Wide Web"
msgstr "World Wide Web"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:286
msgid "Correct. Capitalize each word. Abbreviate as \"WWW\" or \"Web.\""
msgstr "適切です。各単語を大文字にします。省略形は「WWW」または「Web」を使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:289
msgid "Webpage"
msgstr "Webpage"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:290
msgid "Correct. Do not use \"web page\" or \"Web page.\""
msgstr "適切です。「web page」または「Web page」は使用しないでください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:293
msgid "Web server"
msgstr "Web server"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:294
msgid "Correct. Do not use \"webserver\". For example, \"The Apache HTTP Server is the default Web server...\""
msgstr "適切です。「webserver」は使用しないでください。たとえば、「The Apache HTTP Server is the default Web server...」(Apache HTTP サーバーはデフォルトの Web サーバー...) です。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:297
msgid "Website"
msgstr "Website"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:298
msgid "Correct. Do not use \"web site\" or \"Web site.\" For example, \"The Ansible website contains ...\""
msgstr "適切です。「web site」または「Web site」は使用しないでください。たとえば、「The Ansible website contains ...」(Ansible web サイトに...含まれます) となります。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:301
msgid "Who/whom"
msgstr "Who/whom"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:302
msgid "Use the pronoun \"who\" as a subject. Use the pronoun \"whom\" as a direct object, an indirect object, or the object of a preposition. For example: Who owns this? To whom does this belong?"
msgstr "主語には、代名詞「who」を使用します。直接目的語、間接目的語、または前置詞の目的語には、代名詞の目的格「whom」を使用します。たとえば、「Who owns this?」(これは誰が所有していますか?) や、「To whom does this belong?」(これは誰のものですか?) となります。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:305
msgid "Will"
msgstr "Will"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:306
msgid "Do not use future tense unless it is absolutely necessary. For instance, do not use the sentence, \"The next section will describe the process in more detail.\" Instead, use the sentence, \"The next section describes the process in more detail.\""
msgstr "絶対に必要な場合を除いて、未来時制は使用しないでください。たとえば、「The next section will describe the process in more detail.」(次のセクションでプロセスを詳しく説明します) ではなく、「The next section describes the process in more detail.」とします。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:309
msgid "Wish"
msgstr "Wish"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:310
msgid "Use \"need\" instead of \"desire\" and \"wish.\" Use \"want\" when the reader's actions are optional (that is, they may not \"need\" something but may still \"want\" something)."
msgstr "「desire」および「wish」の代わりに「need」を使用します。読者の操作が任意の場合 (つまり、何かを「必要」とはしないかもしれないけど、それでも何かを「望んでいる」可能性がある場合) は「want」を使用します。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:313
msgid "x86"
msgstr "x86"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:314
msgid "Correct. Do not capitalize the \"x.\""
msgstr "適切です。「x」は大文字にしないでください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:317
msgid "x86_64"
msgstr "x86_64"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:318
msgid "Do not use. Do not use \"Hammer\". Always use \"AMD64 and Intel® EM64T\" when referring to this architecture."
msgstr "「Hammer」を使用しないでください。このアーキテクチャーを参照する場合は必ず「AMD64 and Intel® EM64T」としてください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:321
msgid "You"
msgstr "You"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:322
msgid "Correct. Do not use \"I,\" \"he,\" or \"she.\""
msgstr "適切です。「I」、「he」、「she」は使用しないでください。"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:325
msgid "You may"
msgstr "You may"

#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:326
msgid "Try to avoid using this. For example, \"you may\" can be eliminated from this sentence \"You may double-click on the desktop...\""
msgstr "この表現は使用しないようにしてください。たとえば、「You may double-click on the desktop...」(あなたはデスクトップ上でダブルクリックすることができます...) という意味の文からは「you may」を省くことができます。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:3
msgid "Trademark Usage"
msgstr "商標の使用方法"

#: ../../rst/dev_guide/style_guide/trademarks.rst:4
msgid "Why is it important to use the TM, SM, and ® for our registered marks?"
msgstr "登録商標に TM、SM、および ® を使用することが重要な理由"

#: ../../rst/dev_guide/style_guide/trademarks.rst:6
msgid "Before a trademark is registered with the United States Patent and Trademark Office it is appropriate to use the TM or SM symbol depending whether the product is for goods or services. It is important to use the TM or SM as it is notification to the public that Ansible claims rights to the mark even though it has not yet been registered."
msgstr "商標が米国特許商標局に登録される前に、TM または SM のどちらの記号を使用するのが適切かは、製品が商品用かサービス用かによって異なります。Ansible がそのマークに対する権利を主張していることを公に通知するために、商標が登録される前から TM または SM を使用することが重要です。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:8
msgid "Once the trademark is registered, it is appropriate to use the symbol in place of the TM or SM. The symbol designation must be used in conjunction with the trademark if Ansible is to fully protect its rights. If we don't protect these marks, we run the risk of losing them in the way of Aspirin or Trampoline or Escalator."
msgstr "商標が登録されたら、TM または SM の代わりにシンボルを使用することが適切です。Ansible がその権利を完全に保護する場合は、シンボルと商標を組み合わせて使用する必要があります。これらのマークを保護しないと、アスピリン、トランポリン、エスカレーターなどのように、権利を失う場合があります。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:11
msgid "General Rules:"
msgstr "一般的なルール:"

#: ../../rst/dev_guide/style_guide/trademarks.rst:13
msgid "Trademarks should be used on 1st references on a page or within a section."
msgstr "商標は、ページ内またはセクション内で最初に参照する際に使用する必要があります。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:15
msgid "Use Red Hat® Ansible® Automation Platform or Ansible®, on first reference when referring to products."
msgstr "製品を示す最初の参照では、Red Hat® Ansible® Automation Platform or Ansible® または Ansible® を使用します。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:17
msgid "Use \"Ansible\" alone as the company name, as in \"Ansible announced quarterly results,\" which is not marked."
msgstr "「Ansible」を会社名として使用する場合は、「Ansible announced quarterly results」(Ansible 四半期決算発表) のように、マークを付けずに使用します。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:19
msgid "Also add the trademark disclaimer. * When using Ansible trademarks in the body of written text, you should use the following credit line in a prominent place, usually a footnote."
msgstr "商標の免責事項も追加します。* 文章の本文に Ansible 商標を使用する場合は、目立つ場所、通常は脚注に次のような行を追加する必要があります。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:22
msgid "For Registered Trademarks: - [Name of Trademark] is a registered trademark of Red Hat, Inc. in the United States and other countries."
msgstr "登録商標の場合 - [Name of Trademark] is a registered trademark of Red Hat, Inc. in the United States and other countries."

#: ../../rst/dev_guide/style_guide/trademarks.rst:25
msgid "For Unregistered Trademarks (TMs/SMs): - [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries."
msgstr "非登録商標の場合 (TM/SM): - [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries."

#: ../../rst/dev_guide/style_guide/trademarks.rst:28
msgid "For registered and unregistered trademarks: - [Name of Trademark] is a registered trademark and [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries."
msgstr "登録商標および未登録商標の場合: [Name of Trademark] is a registered trademark and [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries."

#: ../../rst/dev_guide/style_guide/trademarks.rst:32
msgid "Guidelines for the proper use of trademarks:"
msgstr "商標を適切な使用するためのガイドライン:"

#: ../../rst/dev_guide/style_guide/trademarks.rst:34
msgid "Always distinguish trademarks from surround text with at least initial capital letters or in all capital letters."
msgstr "商標を、周囲のテキストと区別するために、少なくとも頭文字を大文字にするか、すべての文字を大文字にします。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:36
msgid "Always use proper trademark form and spelling."
msgstr "常に適切な商標の形式とスペルを使用してください。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:38
msgid "Never use a trademark as a noun. Always use a trademark as an adjective modifying the noun."
msgstr "商標は、動詞として使用しないでください。商標は、常に名詞を修飾する形容詞として使用してください。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:40
msgid "Correct: Red Hat® Ansible® Automation Platform system performance is incredible."
msgstr "正しい使用方法: 「Red Hat® Ansible® Automation Platform system performance is incredible. (Red Hat® Ansible® Automation Platform システムのパフォーマンスは驚異的です)」"

#: ../../rst/dev_guide/style_guide/trademarks.rst:43
msgid "Incorrect: Ansible's performance is incredible."
msgstr "誤った使用方法: 「Ansible's performance is incredible. (Ansible のパフォーマンスは脅威的です)」"

#: ../../rst/dev_guide/style_guide/trademarks.rst:46
msgid "Never use a trademark as a verb. Trademarks are products or services, never actions."
msgstr "商標は、動詞として使用しないでください。商標は製品またはサービスであり、動作ではありません。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:48
msgid "Correct: \"Orchestrate your entire network using Red Hat® Ansible® Automation Platform.\""
msgstr "正しい使用方法: 「Orchestrate your entire network using Red Hat® Ansible® Automation Platform. (Red Hat® Ansible® Automation Platform を使用してネットワーク全体を調整します)」"

#: ../../rst/dev_guide/style_guide/trademarks.rst:51
msgid "Incorrect: \"Ansible your entire network.\""
msgstr "誤った使用方法: Ansible your entire network."

#: ../../rst/dev_guide/style_guide/trademarks.rst:54
msgid "Never modify a trademark to a plural form. Instead, change the generic word from the singular to the plural."
msgstr "商標を複数形に変更しないでください。代わりに、一般的な単語を単数形から複数形に変更します。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:56
msgid "Correct: \"Corporate demand for Red Hat® Ansible® Automation Platform software is surging.\""
msgstr "正しい使用方法: 「Corporate demand for Red Hat® Ansible® Automation Platform software is surging. (Red Hat® Ansible® Automation Platform ソフトウェアに対する企業の需要が急増しています)」"

#: ../../rst/dev_guide/style_guide/trademarks.rst:59
msgid "Incorrect: \"Corporate demand for Ansible is surging.\""
msgstr "誤った使用方法: Corporate demand for Ansible is surging."

#: ../../rst/dev_guide/style_guide/trademarks.rst:62
msgid "Never modify a trademark from its possessive form, or make a trademark possessive. Always use it in the form it has been registered."
msgstr "商標を所有格から変更したり、商標を所有格にしたりしないでください。必ず登録した形を使用してください。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:64
msgid "Never translate a trademark into another language."
msgstr "商標を別の言語に翻訳しないでください。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:66
msgid "Never use trademarks to coin new words or names."
msgstr "商標を使用して新しい単語や名前を作成しないでください。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:68
msgid "Never use trademarks to create a play on words."
msgstr "商標を使用して言葉遊びを作成しないでください。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:70
msgid "Never alter a trademark in any way including through unapproved fonts or visual identifiers."
msgstr "未承認のフォントや視覚的な識別子など、いかなる方法でも商標を変更しないでください。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:72
msgid "Never abbreviate or use any Ansible trademarks as an acronym."
msgstr "Ansible の商標を省略したり、頭文字だけ使用しないでください。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:75
msgid "The importance of Ansible trademarks"
msgstr "Ansible 商標の重要性"

#: ../../rst/dev_guide/style_guide/trademarks.rst:77
msgid "The Ansible trademark and the \"A\" logo in a shaded circle are our most valuable assets. The value of these trademarks encompass the Ansible Brand. Effective trademark use is more than just a name, it defines the level of quality the customer will receive and it ties a product or service to a corporate image. A trademark may serve as the basis for many of our everyday decisions and choices. The Ansible Brand is about how we treat customers and each other. In order to continue to build a stronger more valuable Brand we must use it in a clear and consistent manner."
msgstr "Ansible の商標と、斜線で囲まれた「A」のロゴは、当社の最も価値のある資産です。これらの商標の価値は、Ansible ブランドを包括するものです。効果的な商標の使用は、単なる名前ではなく、お客様が受け取る品質レベルを定義し、製品やサービスを企業イメージに結びつけるものです。商標は、私たちの日常的な意思決定や選択の多くの基礎となるものです。Ansible ブランドは、私たちがお客様と互いにどのように接するかということです。より強力で価値のあるブランドを構築し続けるためには、明確で一貫した方法で使用しなければなりません。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:79
msgid "The mark consists of the letter \"A\" in a shaded circle. As of 5/11/15, this was a pending trademark (registration in process)."
msgstr "このマークは、影付きの円で囲まれた文字「A」で構成されています。2015 年 5 月 11 日の時点で、この商標は係属中 (登録手続き中) でした。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:82
msgid "Common Ansible Trademarks"
msgstr "一般的な Ansible の商標"

#: ../../rst/dev_guide/style_guide/trademarks.rst:83
msgid "Ansible®"
msgstr "Ansible®"

#: ../../rst/dev_guide/style_guide/trademarks.rst:86
msgid "Other Common Trademarks and Resource Sites:"
msgstr "その他の一般的な商標およびリソースのサイト:"

#: ../../rst/dev_guide/style_guide/trademarks.rst:87
msgid "Linux is a registered trademark of Linus Torvalds."
msgstr "Linux は、Linus Torvalds の登録商標です。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:88
msgid "UNIX® is a registered trademark of The Open Group."
msgstr "UNIX® は、The Open Group の登録商標です。"

#: ../../rst/dev_guide/style_guide/trademarks.rst:89
msgid "Microsoft, Windows, Vista, XP, and NT are registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/en-us.aspx"
msgstr "Microsoft, Windows, Vista, XP, and NT are registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/en-us.aspx"

#: ../../rst/dev_guide/style_guide/trademarks.rst:90
msgid "Apple, Mac, Mac OS, Macintosh, Pages and TrueType are either registered trademarks or trademarks of Apple Computer, Inc. in the United States and/or other countries. https://www.apple.com/legal/intellectual-property/trademark/appletmlist.html"
msgstr "Apple, Mac, Mac OS, Macintosh, Pages and TrueType are either registered trademarks or trademarks of Apple Computer, Inc. in the United States and/or other countries. https://www.apple.com/legal/intellectual-property/trademark/appletmlist.html"

#: ../../rst/dev_guide/style_guide/trademarks.rst:91
msgid "Adobe, Acrobat, GoLive, InDesign, Illustrator, PostScript , PhotoShop and the OpenType logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. https://www.adobe.com/legal/permissions/trademarks.html"
msgstr "Adobe, Acrobat, GoLive, InDesign, Illustrator, PostScript , PhotoShop and the OpenType logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. https://www.adobe.com/legal/permissions/trademarks.html"

#: ../../rst/dev_guide/style_guide/trademarks.rst:92
msgid "Macromedia and Macromedia Flash are trademarks of Macromedia, Inc. https://www.adobe.com/legal/permissions/trademarks.html"
msgstr "Macromedia and Macromedia Flash are trademarks of Macromedia, Inc. https://www.adobe.com/legal/permissions/trademarks.html"

#: ../../rst/dev_guide/style_guide/trademarks.rst:93
msgid "IBM is a registered trademark of International Business Machines Corporation. https://www.ibm.com/legal/us/en/copytrade.shtml"
msgstr "IBM is a registered trademark of International Business Machines Corporation. https://www.ibm.com/legal/us/en/copytrade.shtml"

#: ../../rst/dev_guide/style_guide/trademarks.rst:94
msgid "Celeron, Celeron Inside, Centrino, Centrino logo, Core Inside, Intel Core, Intel Inside, Intel Inside logo, Itanium, Itanium Inside, Pentium, Pentium Inside,VTune, Xeon, and Xeon Inside are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. https://www.intel.com/content/www/us/en/legal/trademarks.html"
msgstr "Celeron, Celeron Inside, Centrino, Centrino logo, Core Inside, Intel Core, Intel Inside, Intel Inside logo, Itanium, Itanium Inside, Pentium, Pentium Inside,VTune, Xeon, and Xeon Inside are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. https://www.intel.com/content/www/us/en/legal/trademarks.html"

#: ../../rst/dev_guide/style_guide/voice_style.rst:3
msgid "Voice Style"
msgstr "態のスタイル"

#: ../../rst/dev_guide/style_guide/voice_style.rst:4
msgid "The essence of the Ansible writing style is short sentences that flow naturally together. Mix up sentence structures. Vary sentence subjects. Address the reader directly. Ask a question. And when the reader adjusts to the pace of shorter sentences, write a longer one."
msgstr "Ansible ライティングスタイルの特長は、自然に一緒に流れる短い文です。文法構造は混在させます。文の主題を変化させます。読者に直接話しかけます。質問します。読者が短い文章のペースに順応したら、長い文章を書いてください。"

#: ../../rst/dev_guide/style_guide/voice_style.rst:6
msgid "Write how real people speak..."
msgstr "実際のユーザーが話すように記述します。"

#: ../../rst/dev_guide/style_guide/voice_style.rst:7
msgid "...but try to avoid slang and colloquialisms that might not translate well into other languages."
msgstr "ただし、他言語に適切に翻訳できない可能性のある俗語や口語表現は避けるようにしてください。"

#: ../../rst/dev_guide/style_guide/voice_style.rst:8
msgid "Say big things with small words."
msgstr "小さなことばで大きなことを説明します。"

#: ../../rst/dev_guide/style_guide/voice_style.rst:9
msgid "Be direct. Tell the reader exactly what you want them to do."
msgstr "直接的な表現を使用してください。読み手が実行する必要がある内容を正確に指示します。"

#: ../../rst/dev_guide/style_guide/voice_style.rst:10
msgid "Be honest."
msgstr "誠実に表現します。"

#: ../../rst/dev_guide/style_guide/voice_style.rst:11
msgid "Short sentences show confidence."
msgstr "短い文章は自信を示しています。"

#: ../../rst/dev_guide/style_guide/voice_style.rst:12
msgid "Grammar rules are meant to be bent, but only if the reader knows you are doing this."
msgstr "文法規則は、それは読者が何を説明しているかを理解している場合に限り組み込まれることが意図されています。"

#: ../../rst/dev_guide/style_guide/voice_style.rst:13
msgid "Choose words with fewer syllables for faster reading and better understanding."
msgstr "読みやすく、理解を深めるために、音節が少ない単語を選んでください。"

#: ../../rst/dev_guide/style_guide/voice_style.rst:14
msgid "Think of copy as one-on-one conversations rather than as a speech. It's more difficult to ignore someone who is speaking to you directly."
msgstr "コピーは、聴衆に対するスピーチではなく、1 対 1 の対話と考えてください。直接話しかけている人を無視するのはより困難です。"

#: ../../rst/dev_guide/style_guide/voice_style.rst:15
msgid "When possible, start task-oriented sentences (those that direct a user to do something) with action words. For example: Find software... Contact support... Install the media.... and so forth."
msgstr "可能な場合は、タスク指向の文章 (ユーザーによる作業を指示する項目) は、動作を示す用語で開始します。たとえば、「Find software...」、「Contact support...」、「Install the media...」などです。"

#: ../../rst/dev_guide/style_guide/voice_style.rst:18
msgid "Active Voice"
msgstr "能動態"

#: ../../rst/dev_guide/style_guide/voice_style.rst:19
msgid "Use the active voice (\"Start Linuxconf by typing...\") rather than passive (\"Linuxconf can be started by typing...\") whenever possible. Active voice makes for more lively, interesting reading. Also avoid future tense (or using the term \"will\") whenever possible For example, future tense (\"The screen will display...\") does not read as well as an active voice (\"The screen displays\"). Remember, the users you are writing for most often refer to the documentation while they are using the system, not after or in advance of using the system."
msgstr "可能な限り、受動態 (「Linuxconf can be started by typing...」) ではなく、能動態 (「Start Linuxconf by typing...」) を使用してください。能動態の方がより生き生きとした、注意を引き付ける文章になります。また、未来形 (または「will」の使用) は可能な限り使用しないでください。たとえば、未来形 (「The screen will display...」) と能動態 (「The screen displays」) では、ニュアンスが異なります。読者は、システムの使用前または使用後ではなく、システムの使用中にドキュメントを参照することがほとんどであることに注意してください。"

#: ../../rst/dev_guide/style_guide/why_use.rst:4
msgid "Why Use a Style Guide?"
msgstr "スタイルガイドを使用する理由"

#: ../../rst/dev_guide/style_guide/why_use.rst:6
msgid "Style guides are important because they ensure consistency in the content, look, and feel of a book or a website."
msgstr "スタイルガイドは、ドキュメントまたは Web サイトのコンテンツおよびルックアンドフィールの一貫性を確保するために重要です。"

#: ../../rst/dev_guide/style_guide/why_use.rst:8
msgid "Remember, a style guide is only useful if it is used, updated, and enforced.  Style Guides are useful for engineering-related documentation, sales and marketing materials, support docs, community contributions, and more."
msgstr "スタイルガイドは、使用、更新、および実施される場合にのみ役立つことに注意してください。スタイルガイドは、エンジニアリング関連のドキュメント、営業およびマーケティング用資料、サポートドキュメント、コミュニティーへの貢献などに役立ちます。"

#: ../../rst/dev_guide/style_guide/why_use.rst:10
msgid "As changes are made to the overall Ansible site design, be sure to update this style guide with those changes. Or, should other resources listed below have major revisions, consider including company information here for ease of reference."
msgstr "Ansible サイトのデザイン全体に変更が加えられた場合は、その変更に合わせて本スタイルガイドも更新してください。または、以下に記載されているその他の資料に大幅な改訂がある場合は、参照しやすいようにここに会社情報を含めることを検討してください。"

#: ../../rst/dev_guide/style_guide/why_use.rst:12
msgid "This style guide incorporates current Ansible resources and information so that overall site and documentation consistency can be met."
msgstr "このスタイルガイドには、現在の Ansible リソースと情報が組み込まれているため、サイトとドキュメント全体の一貫性を保つことができます。"

#: ../../rst/dev_guide/testing.rst:5
#: ../../rst/dev_guide/testing_running_locally.rst:7
msgid "Testing Ansible"
msgstr "Ansible のテスト"

#: ../../rst/dev_guide/testing.rst:12
msgid "Why test your Ansible contributions?"
msgstr "Ansible への貢献をテストする理由"

#: ../../rst/dev_guide/testing.rst:14
msgid "If you're a developer, one of the most valuable things you can do is to look at GitHub issues and help fix bugs, since bug-fixing is almost always prioritized over feature development.  Even for non-developers, helping to test pull requests for bug fixes and features is still immensely valuable."
msgstr "開発者にとって、最も価値のあることの 1 つが、GitHub の問題を確認し、バグ修正を手伝うことです。バグ修正は、ほとんど常に、機能開発よりも優先されるためです。開発者ではなくても、バグの修正や機能のプル要求のテストを手伝うことは非常に価値のあることです。"

#: ../../rst/dev_guide/testing.rst:16
msgid "Ansible users who understand how to write playbooks and roles should be able to test their work.  GitHub pull requests will automatically run a variety of tests (for example, Azure Pipelines) that show bugs in action.  However, contributors must also test their work outside of the automated GitHub checks and show evidence of these tests in the PR to ensure that their work will be more likely to be reviewed and merged."
msgstr "Ansible ユーザーは、Playbook とロールの作成方法を理解していれば、自身が作成した作業をテストできるはずです。GitHub プル要求は、バグの動作を示すさまざまなテスト (Azure Pipeline など) を自動的に実行します。ただし、貢献者は、自動化された GitHub チェック以外でも自身の作業をテストし、その証拠を PR で示すと、その作業がレビューされてマージされる可能性が高くなります。"

#: ../../rst/dev_guide/testing.rst:18
msgid "Read on to learn how Ansible is tested, how to test your contributions locally, and how to extend testing capabilities."
msgstr "Ansible のテスト方法、貢献をローカルでテストする方法、およびテスト機能を拡張する方法を説明します。"

#: ../../rst/dev_guide/testing.rst:20
msgid "If you want to learn about testing collections, read :ref:`testing_collections`"
msgstr "コレクションのテストを確認する場合は、「:ref:`testing_collections`」を参照してください。"

#: ../../rst/dev_guide/testing.rst:25
msgid "Types of tests"
msgstr "テストの種類"

#: ../../rst/dev_guide/testing.rst:27
msgid "At a high level we have the following classifications of tests:"
msgstr "テストは、大きく分けて以下のように分類されます。"

#: ../../rst/dev_guide/testing.rst
#: ../../rst/dev_guide/testing/sanity/compile.rst:2
msgid "compile"
msgstr "コンパイル"

#: ../../rst/dev_guide/testing.rst:30
msgid ":ref:`testing_compile`"
msgstr ":ref:`testing_compile`"

#: ../../rst/dev_guide/testing.rst:31
msgid "Test python code against a variety of Python versions."
msgstr "さまざまな Python バージョンに対して python コードをテストします。"

#: ../../rst/dev_guide/testing.rst
msgid "sanity"
msgstr "健全性"

#: ../../rst/dev_guide/testing.rst:34
msgid "Sanity tests are made up of scripts and tools used to perform static code analysis."
msgstr "健全性テストは、静的コード分析の実行に使用されるスクリプトおよびツールで構成されています。"

#: ../../rst/dev_guide/testing.rst:35
msgid "The primary purpose of these tests is to enforce Ansible coding standards and requirements."
msgstr "これらのテストの主な目的は、Ansible コーディングの仕様および要件を適用することです。"

#: ../../rst/dev_guide/testing.rst
msgid "integration"
msgstr "統合"

#: ../../rst/dev_guide/testing.rst:38
msgid "Functional tests of modules and Ansible core functionality."
msgstr "モジュールおよび Ansible コア機能の機能テスト"

#: ../../rst/dev_guide/testing.rst
msgid "units"
msgstr "ユニット"

#: ../../rst/dev_guide/testing.rst:40
#: ../../rst/dev_guide/testing_units_modules.rst:567
msgid ":ref:`testing_units`"
msgstr ":ref:`testing_units`"

#: ../../rst/dev_guide/testing.rst:41
msgid "Tests directly against individual parts of the code base."
msgstr "コードベースの個々の部分に対して直接テストを行います。"

#: ../../rst/dev_guide/testing.rst:45
msgid "Testing within GitHub & Azure Pipelines"
msgstr "GitHub および Azure Pipeline でのテスト"

#: ../../rst/dev_guide/testing.rst:49
msgid "Organization"
msgstr "組織"

#: ../../rst/dev_guide/testing.rst:51
msgid "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."
msgstr "プル要求 (PR: Pull Requests) が作成されると、継続的統合 (CI) ツールである Azure Pipeline を使用してテストが行われます。結果はすべての PR の最後に表示されます。"

#: ../../rst/dev_guide/testing.rst:53
msgid "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:"
msgstr "Azure Pipeline がエラーを検出し、それが PR で変更されたファイルにリンクされると、関連する行が GitHub のコメントとして追加されます。たとえば、以下のようになります。"

#: ../../rst/dev_guide/testing.rst:64
msgid "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:"
msgstr "上記の例から、``--test pep8`` および ``--test validate-modules`` が問題を特定したことが分かります。指定されたコマンドを使用すると、同じテストをローカルで実行して、変更を GitHub にプッシュして Azure Pipeline を待つことなく、すべての問題を修正したことを確認できます。次に例を示します。"

#: ../../rst/dev_guide/testing.rst:66
msgid "If you haven't already got Ansible available, use the local checkout by running:"
msgstr "Ansible がまだ利用できるようになっていない場合は、ローカルでチェックアウトを実行してください。"

#: ../../rst/dev_guide/testing.rst:72
msgid "Then run the tests detailed in the GitHub comment:"
msgstr "次に、GitHub コメントで説明するテストを実行します。"

#: ../../rst/dev_guide/testing.rst:79
msgid "If there isn't a GitHub comment stating what's failed you can inspect the results by clicking on the \"Details\" button under the \"checks have failed\" message at the end of the PR."
msgstr "GitHub のコメントに何が失敗したかが書かれていない場合は、PR の末尾にある「checks have failed」というメッセージの下にある「Details」ボタンをクリックして結果を確認することができます。"

#: ../../rst/dev_guide/testing.rst:82
msgid "Rerunning a failing CI job"
msgstr "失敗した CI ジョブの再実行"

#: ../../rst/dev_guide/testing.rst:84
msgid "Occasionally you may find your PR fails due to a reason unrelated to your change. This could happen for several reasons, including:"
msgstr "時折、変更とは関係のない理由で PR が失敗することがあります。これには、以下のような理由が考えられます。"

#: ../../rst/dev_guide/testing.rst:86
msgid "a temporary issue accessing an external resource, such as a yum or git repo"
msgstr "yum や git リポジトリーなどの外部リソースにアクセスする際に一時的に問題が発生した場合。"

#: ../../rst/dev_guide/testing.rst:87
msgid "a timeout creating a virtual machine to run the tests on"
msgstr "テストを実行するための仮想マシンを作成するタイムアウト。"

#: ../../rst/dev_guide/testing.rst:89
msgid "If either of these issues appear to be the case, you can rerun the Azure Pipelines test by:"
msgstr "これらの問題のいずれかがケースとして表示される場合は、以下を実行して Azure Pipelines テストを再実行できます。"

#: ../../rst/dev_guide/testing.rst:91
msgid "adding a comment with ``/rebuild`` (full rebuild) or ``/rebuild_failed`` (rebuild only failed CI nodes) to the PR"
msgstr "``/rebuild`` (完全な再構築) または ``/rebuild_failed`` (構築に失敗した CI ノードのみの再構築) でのコメントを追加する"

#: ../../rst/dev_guide/testing.rst:92
msgid "closing and re-opening the PR (full rebuild)"
msgstr "PR を閉じて再度開く (完全な再構築)"

#: ../../rst/dev_guide/testing.rst:93
msgid "making another change to the PR and pushing to GitHub"
msgstr "PR に何らかの変更を加えて GitHub にプッシュする"

#: ../../rst/dev_guide/testing.rst:95
msgid "If the issue persists, please contact us in 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でMatrixを使用、または`irc.libera.chat <https://libera.chat/>`_でIRCを使用）。"

#: ../../rst/dev_guide/testing.rst:99
msgid "How to test a PR"
msgstr "PR をテストする方法"

#: ../../rst/dev_guide/testing.rst:101
msgid "Ideally, code should add tests that prove that the code works. That's not always possible and tests are not always comprehensive, especially when a user doesn't have access to a wide variety of platforms, or is using an API or web service. In these cases, live testing against real equipment can be more valuable than automation that runs against simulated interfaces. In any case, things should always be tested manually the first time as well."
msgstr "理想的には、コードが機能することを証明するテストを追加することが推奨されます。特に、ユーザーがさまざまなプラットフォームにアクセスできない場合、または API や Web サービスを使用している場合は、これが必ずしも可能ではなく、テストも必ずしも包括的ではありません。このような場合は、シミュレーションされたインターフェースに対して実行される自動化よりも、実際の機器を使用したライブテストの方が有益となります。いずれにせよ、最初の段階でも常に手動でテストする必要があります。"

#: ../../rst/dev_guide/testing.rst:103
msgid "Thankfully, helping to test Ansible is pretty straightforward, assuming you are familiar with how Ansible works."
msgstr "Ansible の動作を熟知していれば、Ansible のテストを手伝うことは非常に簡単です。"

#: ../../rst/dev_guide/testing.rst:106
msgid "Setup: Checking out a Pull Request"
msgstr "設定: プル要求のチェックアウト"

#: ../../rst/dev_guide/testing.rst:108
msgid "You can do this by:"
msgstr "これは、以下の方法で実行できます。"

#: ../../rst/dev_guide/testing.rst:110
msgid "checking out Ansible"
msgstr "Ansible のチェックアウト"

#: ../../rst/dev_guide/testing.rst:111
msgid "fetching the proposed changes into a test branch"
msgstr "提案された変更をテストブランチに取得"

#: ../../rst/dev_guide/testing.rst:112
msgid "testing"
msgstr "テスト"

#: ../../rst/dev_guide/testing.rst:113
msgid "commenting on that particular issue on GitHub"
msgstr "GitHub に特定の問題についてのコメント"

#: ../../rst/dev_guide/testing.rst:115
msgid "Here's how:"
msgstr "以下に、実行する方法を説明します。"

#: ../../rst/dev_guide/testing.rst:118
msgid "Testing source code from GitHub pull requests sent to us does have some inherent risk, as the source code sent may have mistakes or malicious code that could have a negative impact on your system. We recommend doing all testing on a virtual machine, whether a cloud instance, or locally.  Some users like Vagrant or Docker for this, but they are optional. It is also useful to have virtual machines of different Linux or other flavors, since some features (for example, package managers such as apt or yum) are specific to those OS versions."
msgstr "GitHub のプル要求から送られてきたソースコードをテストすることにはリスクが伴います。送られてきたソースコードには、間違いや悪意のあるコードが含まれていて、システムに影響を及ぼす可能性があるからです。すべてのテストは、仮想マシン上で行うことが推奨されます。クラウドインスタンスでもローカルでもかまいません。このために Vagrant や Docker を好むユーザーもいますが、これらは任意です。また、いくつかの機能 (たとえば、apt や yum などのパッケージマネージャー) は、それらの OS バージョンに固有のものであるため、異なる Linux やその他のフレーバーの仮想マシンを用意しておくと便利です。"

#: ../../rst/dev_guide/testing.rst:125
msgid "Create a fresh area to work:"
msgstr "作業用に新しい領域を作成します。"

#: ../../rst/dev_guide/testing.rst:132
msgid "Next, find the pull request you'd like to test and make note of its number. It will look something like this::"
msgstr "次に、テストするプル要求を見つけて、その番号を書き留めます。次のようになります。"

#: ../../rst/dev_guide/testing.rst:136
msgid "Only test ``ansible:devel``"
msgstr "``ansible:devel`` のみをテストします。"

#: ../../rst/dev_guide/testing.rst:138
msgid "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."
msgstr "他のブランチへのプル要求は使用できないため、PR 要求のターゲットは ``ansible:devel`` にすることが重要です。ドットリリースは、Ansible のスタッフが入念に選択しています。"

#: ../../rst/dev_guide/testing.rst:140
msgid "Use the pull request number when you fetch the proposed changes and create your branch for testing:"
msgstr "提案された変更を取得し、テスト用にブランチを作成するときにプル要求番号を使用します。"

#: ../../rst/dev_guide/testing.rst:147
msgid "The first command fetches the proposed changes from the pull request and creates a new branch named ``testing_PRXXXX``, where the XXXX is the actual number associated with the pull request (for example, 65381). The second command checks out the newly created branch."
msgstr "1 つ目のコマンドはプル要求から提案された変更を取得し、``testing_PRXXXX`` という名前の新規ブランチを作成します。XXXX はプル要求に関連する実際の番号 (例: 65381) です。2 つ目のコマンドは、新たに作成されたブランチをチェックアウトします。"

#: ../../rst/dev_guide/testing.rst:150
msgid "If the GitHub user interface shows that the pull request will not merge cleanly, we do not recommend proceeding if you are not somewhat familiar with git and coding, as you will have to resolve a merge conflict. This is the responsibility of the original pull request contributor."
msgstr "GitHub ユーザーインターフェースで、プル要求が正常にマージされないと示された場合は、マージの競合を解決しなければならないため、git およびコーディングにあまり精通していない場合は、続行しないことが推奨されます。これは、元のプル要求の投稿者の責任です。"

#: ../../rst/dev_guide/testing.rst:153
msgid "Some users do not create feature branches, which can cause problems when they have multiple, unrelated commits in their version of ``devel``. If the source looks like ``someuser:devel``, make sure there is only one commit listed on the pull request."
msgstr "一部のユーザーは機能ブランチを作成しないため、``devel`` のバージョンに関連性のないコミットが複数ある場合に、問題が発生する可能性があります。ソースが ``someuser:devel`` のように表示される場合は、プル要求に記載されているコミットが 1 つだけであることを確認してください。"

#: ../../rst/dev_guide/testing.rst:155
msgid "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."
msgstr "Ansible のソースには、Ansible の開発者が頻繁に使用するフルインストールを必要とせず、ソースから直接 Ansible を使用するようにするスクリプトが含まれています。"

#: ../../rst/dev_guide/testing.rst:158
msgid "Simply source it (to use the Linux/Unix terminology) to begin using it immediately:"
msgstr "ソースを作成するだけ (Linux/Unix の用語を使用するために) で、すぐに使い始めることができます。"

#: ../../rst/dev_guide/testing.rst:164
msgid "This script modifies the ``PYTHONPATH`` environment variables (along with a few other things), which will be temporarily set as long as your shell session is open."
msgstr "このスクリプトは、``PYTHONPATH`` 環境変数を変更します (他にもいくつかあります)。これは、シェルセッションが開いている間は一時的に設定されます。"

#: ../../rst/dev_guide/testing.rst:168
msgid "Testing the Pull Request"
msgstr "プル要求のテスト"

#: ../../rst/dev_guide/testing.rst:170
msgid "At this point, you should be ready to begin testing!"
msgstr "この時点でテストを開始する準備が整いました。"

#: ../../rst/dev_guide/testing.rst:172
msgid "Some ideas of what to test are:"
msgstr "何をテストするかのアイデアをいくつか挙げてみましょう。"

#: ../../rst/dev_guide/testing.rst:174
msgid "Create a test Playbook with the examples in and check if they function correctly"
msgstr "例題を含むテスト Playbook を作成し、それらが正しく機能するかどうかを確認します。"

#: ../../rst/dev_guide/testing.rst:175
msgid "Test to see if any Python backtraces returned (that's a bug)"
msgstr "Python のバックトレースが返されているかどうかをテストします (これはバグです)。"

#: ../../rst/dev_guide/testing.rst:176
msgid "Test on different operating systems, or against different library versions"
msgstr "異なるオペレーティングシステムで、または異なるバージョンのライブラリーに対してテストを行います。"

#: ../../rst/dev_guide/testing.rst:179
msgid "Run sanity tests"
msgstr "健全性テストの実行"

#: ../../rst/dev_guide/testing.rst:185
msgid "More information: :ref:`testing_sanity`"
msgstr "詳細情報: :ref:`testing_sanity`"

#: ../../rst/dev_guide/testing.rst:188
msgid "Run unit tests"
msgstr "ユニットテストの実行"

#: ../../rst/dev_guide/testing.rst:194
msgid "More information: :ref:`testing_units`"
msgstr "詳細情報: :ref:`testing_units`"

#: ../../rst/dev_guide/testing.rst:197
msgid "Run integration tests"
msgstr "統合テストの実行"

#: ../../rst/dev_guide/testing.rst:203
msgid "More information: :ref:`testing_integration`"
msgstr "詳細情報: :ref:`testing_integration`"

#: ../../rst/dev_guide/testing.rst:205
msgid "Any potential issues should be added as comments on the pull request (and it's acceptable to comment if the feature works as well), remembering to include the output of ``ansible --version``"
msgstr "潜在的な問題があれば、プル要求にコメントを追加する必要があります (機能が正常に動作する場合もコメントしてもかまいません)。忘れずに ``ansible --version`` の出力を転載してください。"

#: ../../rst/dev_guide/testing.rst:207
msgid "Example::"
msgstr "例:"

#: ../../rst/dev_guide/testing.rst:211
msgid "If the PR does not resolve the issue, or if you see any failures from the unit/integration tests, just include that output instead:"
msgstr "PR が問題を解決しない場合や、ユニット/統合テストでエラーが発生した場合は、代わりにその出力を転載してください。"

#: ../../rst/dev_guide/testing.rst
msgid "This change causes errors for me."
msgstr "この変更により、エラーが発生します。"

#: ../../rst/dev_guide/testing.rst
msgid "When I ran this Ubuntu 16.04 it failed with the following:"
msgstr "When I ran this Ubuntu 16.04 it failed with the following:"

#: ../../rst/dev_guide/testing.rst
msgid "\\```"
msgstr "\\```"

#: ../../rst/dev_guide/testing.rst
msgid "some output"
msgstr "some output"

#: ../../rst/dev_guide/testing.rst
msgid "StackTrace"
msgstr "StackTrace"

#: ../../rst/dev_guide/testing.rst
msgid "some other output"
msgstr "some other output"

#: ../../rst/dev_guide/testing.rst:224
msgid "Code Coverage Online"
msgstr "オンラインのコードカバレージ"

#: ../../rst/dev_guide/testing.rst:226
msgid "`The online code coverage reports <https://codecov.io/gh/ansible/ansible>`_ are a good way to identify areas for testing improvement in Ansible.  By following red colors you can drill down through the reports to find files which have no tests at all.  Adding both integration and unit tests which show clearly how code should work, verify important Ansible functions and increase testing coverage in areas where there is none is a valuable way to help improve Ansible."
msgstr "`オンラインコードカバレージレポート <https://codecov.io/gh/ansible/ansible>`_ は、Ansible でテストが向上する領域を特定するのが適切な方法です。赤い色に従うことで、レポートを掘り下げて、テストがまったくないファイルを見つけることができます。コードがどのように機能するかを明確に示す統合テストとユニットテストの両方を追加し、重要な Ansible 関数を検証し、存在しない領域でテスト範囲を拡大することは、Ansible の改善に役立つ貴重な方法です。"

#: ../../rst/dev_guide/testing.rst:233
msgid "The code coverage reports only cover the ``devel`` branch of Ansible where new feature development takes place.  Pull requests and new code will be missing from the codecov.io coverage reports so local reporting is needed.  Most ``ansible-test`` commands allow you to collect code coverage, this is particularly useful to indicate where to extend testing. See :ref:`testing_running_locally` for more information."
msgstr "コードカバレッジレポートは、新しい機能開発が行われる Ansible の ``devel`` ブランチのみを対象とします。プル要求および新規コードは codecov.io のカバレッジレポートに含まれないため、ローカルレポートが必要になるようです。ほとんどの ``ansible-test`` コマンドでは、コードカバレッジを収集できます。これは、テストを拡張する場所を示すのに特に役に立ちます。詳細は、「:ref:`testing_running_locally`」を参照してください。"

#: ../../rst/dev_guide/testing.rst:241
msgid "Want to know more about testing?"
msgstr "テストに関する詳細情報"

#: ../../rst/dev_guide/testing.rst:243
msgid "If you'd like to know more about the plans for improving testing Ansible then why not join the `Testing Working Group <https://github.com/ansible/community/blob/main/meetings/README.md>`_."
msgstr "Ansible テストを改善する詳細な計画を確認したい場合は、`Testing Working Group <https://github.com/ansible/community/blob/main/meetings/README.md>`_ にご参加ください。"

#: ../../rst/dev_guide/testing/sanity/action-plugin-docs.rst:2
msgid "action-plugin-docs"
msgstr "action-plugin-docs"

#: ../../rst/dev_guide/testing/sanity/action-plugin-docs.rst:4
msgid "Each action plugin should have a matching module of the same name to provide documentation."
msgstr "各アクションプラグインには、ドキュメントを提供するモジュールと同じ名前のモジュールが必要です。"

#: ../../rst/dev_guide/testing/sanity/ansible-doc.rst:2
msgid "ansible-doc"
msgstr "ansible-doc"

#: ../../rst/dev_guide/testing/sanity/ansible-doc.rst:4
msgid "Verifies that ``ansible-doc`` can parse module documentation on all supported Python versions."
msgstr "``ansible-doc`` が、サポートされているすべての Python バージョンでモジュールドキュメントを解析できることを確認します。"

#: ../../rst/dev_guide/testing/sanity/ansible-requirements.rst:2
msgid "ansible-requirements"
msgstr "ansible-requirements"

#: ../../rst/dev_guide/testing/sanity/ansible-requirements.rst:4
msgid "``test/lib/ansible_test/_data/requirements/sanity.import-plugins.txt`` must be an identical copy of ``requirements.txt`` found in the project's root."
msgstr "``test/lib/ansible_test/_data/requirements/sanity.import-plugins.txt`` は、プロジェクトのルートにある ``requirements.txt`` と同じコピーである必要があります。"

#: ../../rst/dev_guide/testing/sanity/ansible-test-future-boilerplate.rst:2
msgid "ansible-test-future-boilerplate"
msgstr "ansible-test-future-boilerplate"

#: ../../rst/dev_guide/testing/sanity/ansible-test-future-boilerplate.rst:4
msgid "The ``_internal`` code for ``ansible-test`` requires the following ``__future__`` import:"
msgstr "``ansible-test`` の``_internal`` コードには、以下の``__future__`` のインポートが必要です。"

#: ../../rst/dev_guide/testing/sanity/ansible-var-precedence-check.rst:4
msgid "ansible-var-precedence-check"
msgstr "ansible-var-precedence-check"

#: ../../rst/dev_guide/testing/sanity/ansible-var-precedence-check.rst:6
msgid "Check the order of precedence for Ansible variables against :ref:`ansible_variable_precedence`."
msgstr "「:ref:`ansible_variable_precedence`」で、Ansible 変数の優先順位の順序を確認します。"

#: ../../rst/dev_guide/testing/sanity/azure-requirements.rst:4
msgid "azure-requirements"
msgstr "azure-requirements"

#: ../../rst/dev_guide/testing/sanity/azure-requirements.rst:6
msgid "Update the Azure integration test requirements file when changes are made to the Azure packaging requirements file:"
msgstr "Azure パッケージ化の要件ファイルに変更が加えられたら、Azure 統合テスト要件ファイルを更新します。"

#: ../../rst/dev_guide/testing/sanity/bin-symlinks.rst:2
msgid "bin-symlinks"
msgstr "bin-symlinks"

#: ../../rst/dev_guide/testing/sanity/bin-symlinks.rst:4
msgid "The ``bin/`` directory in Ansible must contain only symbolic links to executable files. These files must reside in the ``lib/ansible/`` or ``test/lib/ansible_test/`` directories."
msgstr "Ansible の ``bin/`` ディレクトリーには、実行ファイルへのシンボリックリンクのみが含まれている必要があります。これらのファイルは、``lib/ansible/`` ディレクトリーまたは ``test/lib/ansible_test/`` ディレクトリーに置かれている必要があります。"

#: ../../rst/dev_guide/testing/sanity/bin-symlinks.rst:7
msgid "This is required to allow ``ansible-test`` to work with containers and remote hosts when running from an installed version of Ansible."
msgstr "これは、インストール済みバージョンの Ansible から実行する際に、``ansible-test`` がコンテナーおよびリモートホストで動作できるようにするために必要です。"

#: ../../rst/dev_guide/testing/sanity/bin-symlinks.rst:9
msgid "Symlinks for each entry point in ``bin/`` must also be present in ``test/lib/ansible_test/_util/target/injector/``. Each symlink should point to the ``python.py`` script in the same directory. This facilitates running with the correct Python interpreter and enabling code coverage."
msgstr "``bin/`` の各エントリーポイントのシンボリックリンクも ``test/lib/ansible_test/_util/target/injector/`` に存在する必要があります。それぞれのシンボリックリンクは同じディレクトリー内の ``python.py`` スクリプトを指定する必要があります。これにより、正しい Python インタープリターでの実行とコードのカバレッジの有効化が容易になります。"

#: ../../rst/dev_guide/testing/sanity/boilerplate.rst:4
msgid "boilerplate"
msgstr "boilerplate"

#: ../../rst/dev_guide/testing/sanity/boilerplate.rst:6
msgid "Most Python files should include the following boilerplate:"
msgstr "ほとんどの Python ファイルには以下の boilerplate が必要です。"

#: ../../rst/dev_guide/testing/sanity/botmeta.rst:2
msgid "botmeta"
msgstr "botmeta"

#: ../../rst/dev_guide/testing/sanity/botmeta.rst:4
msgid "Verifies that ``./github/BOTMETA.yml`` is valid."
msgstr "``./github/BOTMETA.yml`` が有効であることを確認します。"

#: ../../rst/dev_guide/testing/sanity/changelog.rst:2
msgid "changelog"
msgstr "changelog"

#: ../../rst/dev_guide/testing/sanity/changelog.rst:4
msgid "Basic linting of changelog fragments with `antsibull-changelog lint <https://pypi.org/project/antsibull-changelog/>`_."
msgstr "`antsibull-changelog lint <https://pypi.org/project/antsibull-changelog/>`_ を使用した changelog フラグメントの基本的な文法チェックです。"

#: ../../rst/dev_guide/testing/sanity/changelog.rst:6
msgid "One or more of the following sections are required:"
msgstr "以下のセクションが 1 つ以上必要です。"

#: ../../rst/dev_guide/testing/sanity/changelog.rst:8
msgid "major_changes"
msgstr "major_changes"

#: ../../rst/dev_guide/testing/sanity/changelog.rst:9
msgid "minor_changes"
msgstr "minor_changes"

#: ../../rst/dev_guide/testing/sanity/changelog.rst:10
msgid "breaking_changes"
msgstr "breaking_changes"

#: ../../rst/dev_guide/testing/sanity/changelog.rst:11
msgid "deprecated_features"
msgstr "deprecated_features"

#: ../../rst/dev_guide/testing/sanity/changelog.rst:12
msgid "removed_features"
msgstr "removed_features"

#: ../../rst/dev_guide/testing/sanity/changelog.rst:13
msgid "security_fixes"
msgstr "security_fixes"

#: ../../rst/dev_guide/testing/sanity/changelog.rst:14
msgid "bugfixes"
msgstr "bugfixes"

#: ../../rst/dev_guide/testing/sanity/changelog.rst:15
msgid "known_issues"
msgstr "known_issues"

#: ../../rst/dev_guide/testing/sanity/changelog.rst:17
msgid "New modules and plugins must not be included in changelog fragments."
msgstr "新しいモジュールおよびプラグインは、changelog フラグメントに含めることができません。"

#: ../../rst/dev_guide/testing/sanity/changelog.rst:19
msgid "See :ref:`collection_changelogs` for details."
msgstr "詳しくは、:ref:`collection_changelogs` を参照してください。"

#: ../../rst/dev_guide/testing/sanity/compile.rst:4
msgid "See :ref:`testing_compile` for more information."
msgstr "詳細は、「:ref:`testing_compile`」を参照してください。"

#: ../../rst/dev_guide/testing/sanity/configure-remoting-ps1.rst:2
msgid "configure-remoting-ps1"
msgstr "configure-remoting-ps1"

#: ../../rst/dev_guide/testing/sanity/configure-remoting-ps1.rst:4
msgid "The file ``examples/scripts/ConfigureRemotingForAnsible.ps1`` is required and must be a regular file. It is used by external automated processes and cannot be moved, renamed or replaced with a symbolic link."
msgstr "``examples/scripts/ConfigureRemotingForAnsible.ps1`` ファイルは必須であり、通常のファイルである必要があります。これは外部の自動化プロセスによって使用され、移動したり、名前を変更したり、シンボリックリンクに置き換えたりすることはできません。"

#: ../../rst/dev_guide/testing/sanity/deprecated-config.rst:4
msgid "deprecated-config"
msgstr "非推奨の設定"

#: ../../rst/dev_guide/testing/sanity/deprecated-config.rst:6
msgid "``DOCUMENTATION`` config is scheduled for removal"
msgstr "``DOCUMENTATION`` 設定は削除される予定です。"

#: ../../rst/dev_guide/testing/sanity/docs-build.rst:2
msgid "docs-build"
msgstr "docs-build"

#: ../../rst/dev_guide/testing/sanity/docs-build.rst:4
msgid "Verifies that ``make singlehtmldocs`` in ``docs/docsite/`` completes without errors."
msgstr "``docs/docsite/`` の ``make singlehtmldocs`` が完了し、エラーがないことを確認します。"

#: ../../rst/dev_guide/testing/sanity/empty-init.rst:2
msgid "empty-init"
msgstr "empty-init"

#: ../../rst/dev_guide/testing/sanity/empty-init.rst:4
msgid "The ``__init__.py`` files under the following directories must be empty.  For some of these (modules and tests), ``__init__.py`` files with code won't be used.  For others (module_utils), we want the possibility of using Python namespaces which an empty ``__init__.py`` will allow for."
msgstr "以下のディレクトリーにある ``__init__.py`` ファイルは空である必要があります。これらのディレクトリーの一部 (モジュールおよびテスト) では、コードを持つ ``__init__.py`` ファイルは使用されません。その他 (モジュールユーティリティー) の場合は、空の ``__init__.py`` を許可する Python 名前空間を使用することも可能です。"

#: ../../rst/dev_guide/testing/sanity/empty-init.rst:8
#: ../../rst/dev_guide/testing/sanity/mypy.rst:11
msgid "``lib/ansible/modules/``"
msgstr "``lib/ansible/modules/``"

#: ../../rst/dev_guide/testing/sanity/empty-init.rst:9
#: ../../rst/dev_guide/testing/sanity/mypy.rst:12
msgid "``lib/ansible/module_utils/``"
msgstr "``lib/ansible/module_utils/``"

#: ../../rst/dev_guide/testing/sanity/empty-init.rst:10
msgid "``test/units/``"
msgstr "``test/units/``"

#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:2
msgid "future-import-boilerplate"
msgstr "future-import-boilerplate"

#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:4
msgid "Most Python files should include the following boilerplate at the top of the file, right after the comment header:"
msgstr "ほとんどの Python ファイルには、ファイルの上部、コメントヘッダーの直後に次の boilerplate を含める必要があります。"

#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:11
msgid "This uses Python 3 semantics for absolute vs relative imports, division, and print.  By doing this, we can write code which is portable between Python 2 and Python 3 by following the Python 3 semantics."
msgstr "ここでは、絶対的インポートと相対的インポート、除算、および出力に Python 3 セマンティクスを使用します。Python 3 セマンティクスに従って、Python 2 と Python 3 の間で移植可能なコードを作成できます。"

#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:18
msgid "When Python 2 encounters an import of a name in a file like ``import copy`` it attempts to load ``copy.py`` from the same directory as the file is in.  This can cause problems if there is a python file of that name in the directory and also a python module in ``sys.path`` with that same name.  In that case, Python 2 would load the one in the same directory and there would be no way to load the one on ``sys.path``.  Python 3 fixes this by making imports absolute by default.  ``import copy`` will find ``copy.py`` from ``sys.path``.  If you want to import ``copy.py`` from the same directory, the code needs to be changed to perform a relative import: ``from . import copy``."
msgstr "Python 2 は、``import copy`` のようなファイル名の「import」に遭遇すると、そのファイルがあるディレクトリーから ``copy.py`` を読み込もうとします。これは、そのディレクトリーにその名前の python ファイルがあり、``sys.path`` にも同じ名前の python モジュールがある場合に問題が発生します。この場合、Python 2 は同じディレクトリーにあるものを読み込み、``sys.path`` にあるものを読み込む方法がありません。Python 3 は、デフォルトでインポートを行うようにすることでこの問題を解決しました。``import copy`` は、``sys.path`` から ``copy.py`` を見つけます。同じディレクトリーから ``copy.py`` をインポートする場合は、相対インポートを行うようにコードを変更する必要があります (``from . import copy``)。"

#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:28
msgid "`Absolute and relative imports <https://www.python.org/dev/peps/pep-0328>`_"
msgstr "`絶対および相対のインポート <https://www.python.org/dev/peps/pep-0328>`_"

#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:33
msgid "In Python 2, the division operator (``/``) returns integer values when used with integers.  If there was a remainder, this part would be left off (aka, `floor division`).  In Python 3, the division operator (``/``) always returns a floating point number.  Code that needs to calculate the integer portion of the quotient needs to switch to using the floor division operator (`//`) instead."
msgstr "Python 2 では、除算演算子 (``/``) は、整数と共に使用すると整数値を返します。残りの部分がある場合、この部分はオフ (別名 `切り捨て除算`) のままにします。Python 3 では、除算演算子 (``/``) は常に浮動小数点数を返します。引用符で整数を計算する必要のあるコードは、代わりに切り捨て除算演算子 (`//`) の使用に切り替える必要があります。"

#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:40
msgid "`Changing the division operator <https://www.python.org/dev/peps/pep-0238>`_"
msgstr "`除算演算子の変更 <https://www.python.org/dev/peps/pep-0238>`_"

#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:45
msgid "In Python 2, :func:`python:print` is a keyword.  In Python 3, :func:`python3:print` is a function with different parameters.  Using this ``__future__`` allows using the Python 3 print semantics everywhere."
msgstr "Python 2 では、:func:`python:print` はキーワードです。Python 3 では、 :func:`python3:print` は異なるパラメーターを持つ機能です。この ``__future__`` を使用すると、あらゆる場所に Python 3 出力セマンティクスを使用できます。"

#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:50
msgid "`Make print a function <https://www.python.org/dev/peps/pep-3105>`_"
msgstr "`Make print a function <https://www.python.org/dev/peps/pep-3105>`_"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:2
msgid "ignores"
msgstr "ignore"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:4
msgid "Sanity tests for individual files can be skipped, and specific errors can be ignored."
msgstr "個々のファイルで健全性テストをスキップしたり、特定のエラーを無視したりできます。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:7
msgid "When to Ignore Errors"
msgstr "エラーを無視するタイミング"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:9
msgid "Sanity tests are designed to improve code quality and identify common issues with content. When issues are identified during development, those issues should be corrected."
msgstr "健全性テストは、コードの品質を改善し、コンテンツに関する典型的な問題を特定するように設計されています。開発中に問題を特定する際に、問題を修正する必要があります。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:12
msgid "As development of Ansible continues, sanity tests are expanded to detect issues that previous releases could not. To allow time for existing content to be updated to pass newer tests, ignore entries can be added. New content should not use ignores for existing sanity tests."
msgstr "Ansible の開発が続くにつれて、健全性テストが拡張され、以前のリリースでは検出できなかった問題が検出されます。既存のコンテンツを更新して新しいテストに合格するための時間を確保するために、ignore エントリーを追加できます。新しいコンテンツでは、既存の健全性テストで ignore を使用しないでください。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:16
msgid "When code is fixed to resolve sanity test errors, any relevant ignores must also be removed. If the ignores are not removed, this will be reported as an unnecessary ignore error. This is intended to prevent future regressions due to the same error recurring after being fixed."
msgstr "コードが修正されて健全性テストエラーを解決する場合には、関連する ignore も削除する必要があります。ignore が削除されないと、不要な ignore エラーが報告されます。これは、修正後に同じエラーが繰り返し発生するため、今後のリグレッションを防ぐことを目的としています。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:21
msgid "When to Skip Tests"
msgstr "テストをスキップするタイミング"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:23
msgid "Although rare, there are reasons for skipping a sanity test instead of ignoring the errors it reports."
msgstr "頻繁には起こりませんが、報告されたエラーを無視する代わりに、健全性テストを行わない (スキップする) 場合があります。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:25
msgid "If a sanity test results in a traceback when processing content, that error cannot be ignored. If this occurs, open a new `bug report <https://github.com/ansible/ansible/issues/new?template=bug_report.md>`_ for the issue so it can be fixed. If the traceback occurs due to an issue with the content, that issue should be fixed. If the content is correct, the test will need to be skipped until the bug in the sanity test is fixed."
msgstr "健全性テストにより、コンテンツの処理時にトレースバックが発生すると、そのエラーは無視できません。このような場合には、新しい `バグレポート <https://github.com/ansible/ansible/issues/new?template=bug_report.md>`_ を作成し、問題を修正してください。コンテンツに問題があるためにトレースバックが発生した場合は、その問題を修正する必要があります。コンテンツが正しい場合は、健全性テストのバグが修正されるまで、テストをスキップする必要があります。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:30
msgid "Caution should be used when skipping sanity tests instead of ignoring them. Since the test is skipped entirely, resolution of the issue will not be automatically detected. This will prevent prevent regression detection from working once the issue has been resolved. For this reason it is a good idea to periodically review skipped entries manually to verify they are required."
msgstr "健全性テストを無視するのではなくスキップする場合は注意が必要です。テストは完全にスキップされるため、問題の解決が自動的に検出されません。これにより、問題が解決すると回帰検出が機能しなくなります。このため、スキップしたエントリーを定期的に手動で確認して、そのエントリーが必要かどうかを確認することが推奨されます。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:36
msgid "Ignore File Location"
msgstr "ignore ファイルの場所"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:38
msgid "The location of the ignore file depends on the type of content being tested."
msgstr "ignore ファイルの場所は、テストするコンテンツの種類によって異なります。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:41
msgid "Ansible Collections"
msgstr "Ansible コレクション"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:43
msgid "Since sanity tests change between Ansible releases, a separate ignore file is needed for each Ansible major release."
msgstr "健全性テストは Ansible リリース間で異なるため、Ansible メジャーリリースごとに個別の ignore ファイルが必要です。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:45
msgid "The filename is ``tests/sanity/ignore-X.Y.txt`` where ``X.Y`` is the Ansible release being used to test the collection."
msgstr "ファイル名は ``tests/sanity/ignore-X.Y.txt`` です。``X.Y`` は、コレクションをテストするために使用される Ansible リリースです。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:47
msgid "Maintaining a separate file for each Ansible release allows a collection to pass tests for multiple versions of Ansible."
msgstr "Ansible リリースごとに個別のファイルを維持すると、コレクションが Ansible の複数のバージョンのテストに合格できるようになります。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:52
msgid "When testing Ansible, all ignores are placed in the ``test/sanity/ignore.txt`` file."
msgstr "Ansible をテストする際、すべての ignore は ``test/sanity/ignore.txt`` ファイルに置かれます。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:54
msgid "Only a single file is needed because ``ansible-test`` is developed and released as a part of Ansible itself."
msgstr "``ansible-test`` が作成され、Ansible 自体の一部としてリリースされるため、単一のファイルのみが必要になります。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:57
msgid "Ignore File Format"
msgstr "ignore ファイル形式"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:59
msgid "The ignore file contains one entry per line. Each line consists of two columns, separated by a single space. Comments may be added at the end of an entry, started with a hash (``#``) character, which can be proceeded by zero or more spaces. Blank and comment only lines are not allowed."
msgstr "ignore ファイルでは、1 行に 1 つのエントリーが含まれます。各行は、1 つのスペースで区切られた 2 つの列で構成されます。コメントはエントリーの末尾に追加できます。先頭にハッシュ (``#``) 文字を付けて、ゼロ以上の空白を追加できます。空白とコメントのみの行は使用できません。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:64
msgid "The first column specifies the file path that the entry applies to. File paths must be relative to the root of the content being tested. This is either the Ansible source or an Ansible collection. File paths cannot contain a space or the hash (``#``) character."
msgstr "最初の列は、エントリーが適用されるファイルパスを指定します。ファイルパスは、テストするコンテンツのルートに対して相対的である必要があります。これは Ansible ソースまたは Ansible コレクションのいずれかです。ファイルパスにスペースまたはハッシュ (``#``) 文字を含めることはできません。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:69
msgid "The second column specifies the sanity test that the entry applies to. This will be the name of the sanity test. If the sanity test is specific to a version of Python, the name will include a dash (``-``) and the relevant Python version. If the named test uses error codes then the error code to ignore must be appended to the name of the test, separated by a colon (``:``)."
msgstr "2 列目は、エントリーが適用される健全性テストを指定します。これが健全性テストの名前になります。Python のバージョンに固有の健全性テストを使用する場合は、名前にダッシュ (``-``) と関連する Python バージョンが含まれます。名前付きテストがエラーコードを使用する場合は、無視するエラーコードをコロン (``:``) で区切ってテストの名前に追加する必要があります。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:74
msgid "Below are some example ignore entries for an Ansible collection::"
msgstr "以下の例は、Ansible コレクションの ignore エントリーの例です。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:80
msgid "It is also possible to skip a sanity test for a specific file. This is done by adding ``!skip`` after the sanity test name in the second column. When this is done, no error code is included, even if the sanity test uses error codes."
msgstr "特定ファイルの健全性テストをスキップすることもできます。これは、2 番目のコラムの健全性テスト名の後に ``!skip`` を追加することで行います。これを行うと、健全性テストでエラーコードを使用しても、エラーコードは含まれません。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:84
msgid "Below are some example skip entries for an Ansible collection::"
msgstr "以下は、Ansible コレクションのエントリーをスキップする例です。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:89
#: ../../rst/dev_guide/testing_sanity.rst:56
msgid "See the full list of :ref:`sanity tests <all_sanity_tests>`, which details the various tests and details how to fix identified issues."
msgstr "各種テストや特定された問題を解決する方法の詳細は、「:ref:`健全性テスト <all_sanity_tests>`」の一覧を参照してください。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:92
msgid "Ignore File Errors"
msgstr "ignore ファイルエラー"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:94
msgid "There are various errors that can be reported for the ignore file itself:"
msgstr "ignore ファイル自体について報告できるさまざまなエラーがあります。"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:96
msgid "syntax errors parsing the ignore file"
msgstr "ignore ファイルを解析する構文エラー"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:97
msgid "references a file path that does not exist"
msgstr "存在しないファイルパスを参照"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:98
msgid "references to a sanity test that does not exist"
msgstr "存在しない健全性テストへの参照"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:99
msgid "ignoring an error that does not occur"
msgstr "発生しないエラーを無視"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:100
msgid "ignoring a file which is skipped"
msgstr "スキップされたファイルを無視"

#: ../../rst/dev_guide/testing/sanity/ignores.rst:101
msgid "duplicate entries"
msgstr "重複エントリー"

#: ../../rst/dev_guide/testing/sanity/import.rst:2
msgid "import"
msgstr "import"

#: ../../rst/dev_guide/testing/sanity/import.rst:4
msgid "Ansible allows unchecked imports of some libraries from specific directories, listed at the bottom of this section. Import all other Python libraries in a try/except ImportError block to support sanity tests such as ``validate-modules`` and to allow Ansible to give better error messages to the user. To import a library in a try/except ImportError block:"
msgstr "Ansible では、このセクションの下部に記載されている特定のディレクトリーから、いくつかのライブラリーを確認せずにインポートすることができます。``validate-modules`` などの健全性テストをサポートし、Ansible がユーザーに適切なエラーメッセージを表示できるようにするため、try/except ImportError ブロックで他のすべての Python ライブラリーをインポートします。try/except ImportError ブロックでライブラリをインポートするには、次を行います。"

#: ../../rst/dev_guide/testing/sanity/import.rst:6
msgid "In modules:"
msgstr "モジュールの場合:"

#: ../../rst/dev_guide/testing/sanity/import.rst:33
msgid "In plugins:"
msgstr "プラグインの場合:"

#: ../../rst/dev_guide/testing/sanity/import.rst:58
msgid "Ansible allows the following unchecked imports from these specific directories:"
msgstr "Ansible では、これらの特定のディレクトリーから次の未確認インポートを許可します。"

#: ../../rst/dev_guide/testing/sanity/import.rst:60
msgid "ansible-core:"
msgstr "ansible-core:"

#: ../../rst/dev_guide/testing/sanity/import.rst:62
msgid "For ``lib/ansible/modules/`` and ``lib/ansible/module_utils/``, unchecked imports are only allowed from the Python standard library;"
msgstr "``lib/ansible/modules/`` および ``lib/ansible/module_utils/`` の場合、未確認インポートは Python 標準ライブラリーでのみ利用可能です。"

#: ../../rst/dev_guide/testing/sanity/import.rst:63
msgid "For ``lib/ansible/plugins/``, unchecked imports are only allowed from the Python standard library, from public dependencies of ansible-core, and from ansible-core itself;"
msgstr "``lib/ansible/plugins/`` では、未確認インポートは、Python 標準ライブラリー、ansible-core のパブリック依存関係、および ansible-core 自体からのみ許可されます。"

#: ../../rst/dev_guide/testing/sanity/import.rst:65
msgid "collections:"
msgstr "コレクション:"

#: ../../rst/dev_guide/testing/sanity/import.rst:67
msgid "For ``plugins/modules/`` and ``plugins/module_utils/``, unchecked imports are only allowed from the Python standard library;"
msgstr "``plugins/modules/`` および ``plugins/module_utils/`` の場合、未確認インポートは Python 標準ライブラリーでのみ利用可能です。"

#: ../../rst/dev_guide/testing/sanity/import.rst:68
msgid "For other directories in ``plugins/`` (see `the community collection requirements <https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#modules-plugins>`_ for a list), unchecked imports are only allowed from the Python standard library, from public dependencies of ansible-core, and from ansible-core itself."
msgstr "``plugins/`` のその他のディレクトリー (一覧は「`the community collection requirements <https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#modules-plugins>`_」を参照) では、未確認インポートは Python 標準ライブラリー、ansible-core のパブリック依存関係、および ansible-core 自体からのみ許可されます。"

#: ../../rst/dev_guide/testing/sanity/import.rst:70
msgid "Public dependencies of ansible-core are:"
msgstr "ansible-core のパブリック依存関係は次のとおりです。"

#: ../../rst/dev_guide/testing/sanity/import.rst:72
msgid "Jinja2"
msgstr "Jinja2"

#: ../../rst/dev_guide/testing/sanity/import.rst:73
msgid "PyYAML"
msgstr "PyYAML"

#: ../../rst/dev_guide/testing/sanity/import.rst:74
msgid "MarkupSafe (as a dependency of Jinja2)"
msgstr "MarkupSafe (Jinja2 の依存関係として)"

#: ../../rst/dev_guide/testing/sanity/index.rst:4
#: ../../rst/dev_guide/testing_sanity.rst:7
msgid "Sanity Tests"
msgstr "健全性テスト"

#: ../../rst/dev_guide/testing/sanity/index.rst:6
msgid "The following sanity tests are available as ``--test`` options for ``ansible-test sanity``. This list is also available using ``ansible-test sanity --list-tests --allow-disabled``."
msgstr "以下の健全性テストは、``ansible-test sanity`` の ``--test`` オプションとして利用できます。この一覧は、``ansible-test sanity --list-tests --allow-disabled`` を使用しても利用できます。"

#: ../../rst/dev_guide/testing/sanity/index.rst:9
msgid "For information on how to run these tests, see :ref:`sanity testing guide <testing_sanity>`."
msgstr "これらのテストの実行方法は、「:ref:`健全性テストガイド <testing_sanity>`」を参照してください。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:2
msgid "integration-aliases"
msgstr "integration-aliases"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:4
msgid "Integration tests are executed by ``ansible-test`` and reside in directories under ``test/integration/targets/``. Each test MUST have an ``aliases`` file to control test execution."
msgstr "統合テストは ``ansible-test`` によって実行し、``test/integration/targets/`` 配下のディレクトリーに置かれます。各テストには、テストの実行を制御する ``aliases`` ファイルが必要です。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:7
msgid "Aliases are explained in the following sections. Each alias must be on a separate line in an ``aliases`` file."
msgstr "エイリアスは、以下のセクションで説明します。各エイリアスは、``aliases`` ファイルの別の行に指定する必要があります。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:10
msgid "Groups"
msgstr "グループ"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:12
msgid "Tests must be configured to run in exactly one group. This is done by adding the appropriate group to the ``aliases`` file."
msgstr "テストは 1 つのグループで実行するように設定する必要があります。これは、適切なグループを ``aliases`` ファイルに追加することで行われます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:14
msgid "The following are examples of some of the available groups:"
msgstr "利用可能な一部のグループの例を以下に示します。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:16
msgid "``shippable/posix/group1``"
msgstr "``shippable/posix/group1``"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:17
msgid "``shippable/windows/group2``"
msgstr "``shippable/windows/group2``"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:18
msgid "``shippable/azure/group3``"
msgstr "``shippable/azure/group3``"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:19
msgid "``shippable/aws/group1``"
msgstr "``shippable/aws/group1``"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:20
msgid "``shippable/cloud/group1``"
msgstr "``shippable/cloud/group1``"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:22
msgid "Groups are used to balance tests across multiple CI jobs to minimize test run time. They also improve efficiency by keeping tests with similar requirements running together."
msgstr "グループは、複数の CI ジョブ間でテストのバランスを取り、テストのランタイムを最小限にするために使用します。同様の要件が一緒に実行されるテストを維持することで、効率性も向上します。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:25
msgid "When selecting a group for a new test, use the same group as existing tests similar to the one being added. If more than one group is available, select one randomly."
msgstr "新規テスト用にグループを選択する場合は、追加する既存のテストと同様のグループを使用します。複数のグループが利用可能な場合は、ランダムに 1 つのグループを選択します。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:29
msgid "Setup"
msgstr "設定"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:31
msgid "Aliases can be used to execute setup targets before running tests:"
msgstr "エイリアスは、テストを実行する前に設定ターゲットを実行するのに使用できます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:33
msgid "``setup/once/TARGET`` - Run the target ``TARGET`` before the first target that requires it."
msgstr "``setup/once/TARGET`` - それが必要な最初のターゲットの前に、ターゲット ``TARGET`` を実行します。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:34
msgid "``setup/always/TARGET`` - Run the target ``TARGET`` before each target that requires it."
msgstr "``setup/always/TARGET`` - 必要な各ターゲットの前にターゲット ``TARGET`` を実行します。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:37
#: ../../rst/dev_guide/testing_running_locally.rst:18
msgid "Requirements"
msgstr "要件"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:39
msgid "Aliases can be used to express some test requirements:"
msgstr "エイリアスを使用すると、一部のテスト要件を表現することができます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:41
msgid "``needs/privileged`` - Requires ``--docker-privileged`` when running tests with ``--docker``."
msgstr "``needs/privileged`` - ``--docker`` でテストを実行する場合は、``--docker-privileged`` が必要です。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:42
msgid "``needs/root`` - Requires running tests as ``root`` or with ``--docker``."
msgstr "``needs/root`` - ``root`` または ``--docker`` でテストを実行する必要があります。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:43
msgid "``needs/ssh`` - Requires SSH connections to localhost (or the test container with ``--docker``) without a password."
msgstr "``needs/ssh`` - パスワードなしで localhost (または ``--docker`` を使用したテストコンテナー) への SSH 接続を必要とします。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:44
msgid "``needs/httptester`` - Requires use of the http-test-container to run tests."
msgstr "``needs/httptester`` - テストを実行するには、http-test-container を使用する必要があります。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:47
msgid "Dependencies"
msgstr "依存関係"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:49
msgid "Some test dependencies are automatically discovered:"
msgstr "一部のテスト依存関係は自動的に検出されます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:51
msgid "Ansible role dependencies defined in ``meta/main.yml`` files."
msgstr "``meta/main.yml`` ファイルで定義される Ansible ロールの依存関係。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:52
msgid "Setup targets defined with ``setup/*`` aliases."
msgstr "``setup/*`` エイリアスで定義されたターゲットのセットアップ。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:53
msgid "Symbolic links from one target to a file in another target."
msgstr "あるターゲットから別のターゲットのファイルへのシンボリックリンク。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:55
msgid "Aliases can be used to declare dependencies that are not handled automatically:"
msgstr "エイリアスを使用すると、自動的に処理されない依存関係を宣言できます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:57
msgid "``needs/target/TARGET`` - Requires use of the test target ``TARGET``."
msgstr "``needs/target/TARGET`` - テストターゲット ``TARGET`` を使用する必要があります。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:58
msgid "``needs/file/PATH`` - Requires use of the file ``PATH`` relative to the git root."
msgstr "``needs/file/PATH`` - git ルートと関連するファイル ``PATH`` を使用する必要があります。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:61
msgid "Skipping"
msgstr "スキップ"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:63
msgid "Aliases can be used to skip platforms using one of the following:"
msgstr "エイリアスを使用すると、以下のいずれかを使用してプラットフォームをスキップできます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:65
msgid "``skip/freebsd`` - Skip tests on FreeBSD."
msgstr "``skip/freebsd`` - FreeBSD のテストをスキップします。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:66
msgid "``skip/osx`` - Skip tests on macOS."
msgstr "``skip/osx`` - macOS でのテストをスキップします。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:67
msgid "``skip/rhel`` - Skip tests on RHEL."
msgstr "``skip/rhel`` - RHEL でのテストをスキップします。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:68
msgid "``skip/docker`` - Skip tests when running in a Docker container."
msgstr "``skip/docker`` - Docker コンテナーで実行する場合はテストをスキップします。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:70
msgid "Platform versions, as specified using the ``--remote`` option with ``/`` removed, can also be skipped:"
msgstr "``--remote`` オプションで ``/`` を削除して指定したプラットフォームバージョンもスキップできます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:72
msgid "``skip/freebsd11.1`` - Skip tests on FreeBSD 11.1."
msgstr "``skip/freebsd11.1`` - FreeBSD 11.1 のテストをスキップします。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:73
msgid "``skip/rhel7.6`` - Skip tests on RHEL 7.6."
msgstr "``skip/rhel7.6`` - RHEL 7.6 でのテストをスキップします。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:75
msgid "Windows versions, as specified using the ``--windows`` option can also be skipped:"
msgstr "``--windows`` オプションを使用して指定する Windows バージョンもスキップできます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:77
msgid "``skip/windows/2012`` - Skip tests on Windows Server 2012."
msgstr "``skip/windows/2012`` - Windows Server 2012 のテストをスキップします。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:78
msgid "``skip/windows/2012-R2`` - Skip tests on Windows Server 2012 R2."
msgstr "``skip/windows/2012-R2`` - Windows Server 2012 R2 のテストをスキップします。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:80
msgid "Aliases can be used to skip Python major versions using one of the following:"
msgstr "エイリアスを使用すると、以下のいずれかを使用して Python のメジャーバージョンをスキップできます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:82
msgid "``skip/python2`` - Skip tests on Python 2.x."
msgstr "``skip/python2`` - Python 2.x のテストをスキップします。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:83
msgid "``skip/python3`` - Skip tests on Python 3.x."
msgstr "``skip/python3`` - Python 3.x のテストをスキップします。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:85
msgid "For more fine grained skipping, use conditionals in integration test playbooks, such as:"
msgstr "より詳細なスキップを行うには、統合テストの Playbook で条件を使用します。以下に例を示します。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:93
msgid "Miscellaneous"
msgstr "その他"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:95
msgid "There are several other aliases available as well:"
msgstr "その他にも利用できるエイリアスがいくつかあります。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:97
msgid "``destructive`` - Requires ``--allow-destructive`` to run without ``--docker`` or ``--remote``."
msgstr "``destructive`` - ``--docker`` または ``--remote`` なしで ``--allow-destructive`` を実行する必要があります。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:98
msgid "``hidden`` - Target is ignored. Usable as a dependency. Automatic for ``setup_`` and ``prepare_`` prefixed targets."
msgstr "``hidden`` - ターゲットは無視されます。依存関係として使用できます。プレフィックス ``setup_`` および ``prepare_`` が付けられたターゲットに対する自動化。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:101
msgid "Unstable"
msgstr "Unstable"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:103
msgid "Tests which fail sometimes should be marked with the ``unstable`` alias until the instability has been fixed. These tests will continue to run for pull requests which modify the test or the module under test."
msgstr "時々失敗するテストは、不安定性が修正されるまで、``unstable`` エイリアスでマークする必要があります。これらのテストは、テストまたはテスト対象のモジュールを変更するプル要求に対して引き続き実行します。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:106
msgid "This avoids unnecessary test failures for other pull requests, as well as tests on merge runs and nightly CI jobs."
msgstr "これにより、他のプル要求に対する不要なテストの失敗や、マージの実行および毎夜の CI ジョブのテストも回避されます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:108
msgid "There are two ways to run unstable tests manually:"
msgstr "不安定なテストを手動で実行する方法は 2 つあります。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:110
msgid "Use the ``--allow-unstable`` option for ``ansible-test``"
msgstr "``ansible-test`` には ``--allow-unstable`` オプションを使用します。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:111
msgid "Prefix the test name with ``unstable/`` when passing it to ``ansible-test``."
msgstr "それを ``ansible-test`` に渡す場合は、テスト名の前にプレフィックス ``unstable/`` を付けます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:113
msgid "Tests will be marked as unstable by a member of the Ansible Core Team. GitHub issues_ will be created to track each unstable test."
msgstr "テストは、Ansible Core Team のメンバーによって Unstable と表示されます。GitHub 問題_ が作成され、不安定な各テストを追跡します。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:117
msgid "Disabled"
msgstr "Disabled"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:119
msgid "Tests which always fail should be marked with the ``disabled`` alias until they can be fixed."
msgstr "常に失敗するテストでは、修正されるまで、``disabled`` なエイリアスでマークされる必要があります。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:121
msgid "Disabled tests are automatically skipped."
msgstr "無効にされたテストは自動的にスキップされます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:123
msgid "There are two ways to run disabled tests manually:"
msgstr "無効にされたテストを手動で実行する方法は 2 つあります。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:125
msgid "Use the ``--allow-disabled`` option for ``ansible-test``"
msgstr "``ansible-test`` には ``--allow-disabled`` オプションを使用します。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:126
msgid "Prefix the test name with ``disabled/`` when passing it to ``ansible-test``."
msgstr "それを ``ansible-test`` に渡す場合は、テスト名の前にプレフィックス ``disabled/`` を付けます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:128
msgid "Tests will be marked as disabled by a member of the Ansible Core Team. GitHub issues_ will be created to track each disabled test."
msgstr "テストは、Ansible Core Team のメンバーによって無効とマークされます。GitHub 問題_ が作成され、無効にされた各テストを追跡します。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:132
msgid "Unsupported"
msgstr "Unsupported"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:134
msgid "Tests which cannot be run in CI should be marked with the ``unsupported`` alias. Most tests can be supported through the use of simulators and/or cloud plugins."
msgstr "CI で実行できないテストには、``unsupported`` エイリアスのマークを付ける必要があります。ほとんどのテストはシミュレーターやクラウドプラグインを使用することでサポートされます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:137
msgid "However, if that is not possible then marking a test as unsupported will prevent it from running in CI."
msgstr "ただし、テストが使用できない場合は、テストを unsupported と表示すると、CI でテストを実行できなくなります。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:139
msgid "There are two ways to run unsupported tests manually:"
msgstr "サポート対象外のテストを手動で実行する方法は 2 つあります。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:141
msgid "Use the ``--allow-unsupported`` option for ``ansible-test``"
msgstr "``ansible-test`` には ``--allow-unsupported`` オプションを使用します。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:142
msgid "Prefix the test name with ``unsupported/`` when passing it to ``ansible-test``."
msgstr "それを ``ansible-test`` に渡す場合は、テスト名の前にプレフィックス ``unsupported/`` を付けます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:144
msgid "Tests will be marked as unsupported by the contributor of the test."
msgstr "テストは、テストの貢献者によって unsupported とマークされます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:147
msgid "Cloud"
msgstr "クラウド"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:149
msgid "Tests for cloud services and other modules that require access to external APIs usually require special support for testing in CI."
msgstr "通常、外部 API へのアクセスを必要とするクラウドサービスおよびその他のモジュールのテストには、CI でのテストに特別なサポートが必要です。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:151
msgid "These require an additional alias to indicate the required test plugin."
msgstr "これらには、必要なテストプラグインを指定するために追加のエイリアスが必要です。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:153
msgid "Some of the available aliases are:"
msgstr "利用可能なエイリアスには、以下のものがあります。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:155
msgid "``cloud/aws``"
msgstr "``cloud/aws``"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:156
msgid "``cloud/azure``"
msgstr "``cloud/azure``"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:157
msgid "``cloud/cs``"
msgstr "``cloud/cs``"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:158
msgid "``cloud/digitalocean``"
msgstr "``cloud/digitalocean``"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:159
msgid "``cloud/foreman``"
msgstr "``cloud/foreman``"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:160
msgid "``cloud/openshift``"
msgstr "``cloud/openshift``"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:161
msgid "``cloud/tower``"
msgstr "``cloud/tower``"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:162
msgid "``cloud/vcenter``"
msgstr "``cloud/vcenter``"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:165
msgid "Untested"
msgstr "未テスト"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:167
msgid "Every module and plugin should have integration tests, even if the tests cannot be run in CI."
msgstr "テストを CI で実行できない場合でも、すべてのモジュールおよびプラグインに統合テストが含まれる必要があります。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:170
msgid "Issues"
msgstr "問題"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:172
msgid "Tests that are marked as unstable_ or disabled_ will have an issue created to track the status of the test. Each issue will be assigned to one of the following projects:"
msgstr "unstable_ または disabled_ としてマークされているテストには、テストのステータスを追跡する問題が作成されます。それぞれの問題は以下のプロジェクトのいずれかに割り当てられます。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:175
msgid "`AWS <https://github.com/ansible/ansible/projects/21>`_"
msgstr "`AWS <https://github.com/ansible/ansible/projects/21>`_"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:176
msgid "`Azure <https://github.com/ansible/ansible/projects/22>`_"
msgstr "`Azure <https://github.com/ansible/ansible/projects/22>`_"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:177
msgid "`Windows <https://github.com/ansible/ansible/projects/23>`_"
msgstr "`Windows <https://github.com/ansible/ansible/projects/23>`_"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:178
msgid "`General <https://github.com/ansible/ansible/projects/25>`_"
msgstr "`General <https://github.com/ansible/ansible/projects/25>`_"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:181
msgid "Questions"
msgstr "ご質問はございますか。"

#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:183
msgid "For questions about integration tests reach out to @mattclay or @gundalow on GitHub or the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat <https://libera.chat/>`_)."
msgstr "統合テストに関する質問は、GitHub で @mattclay もしくは @gundalow、または``#ansible-devel``チャットチャンネル（ansible.imでMatrixを使用、または`irc.libera.chat <https://libera.chat/>`_でIRCを使用）にお問い合わせください。"

#: ../../rst/dev_guide/testing/sanity/line-endings.rst:2
msgid "line-endings"
msgstr "行末"

#: ../../rst/dev_guide/testing/sanity/line-endings.rst:4
msgid "All files must use ``\\n`` for line endings instead of ``\\r\\n``."
msgstr "すべてのファイルは、``\\r\\n"
"`` ではなく、行末に ``\\n"
"`` を使用する必要があります。"

#: ../../rst/dev_guide/testing/sanity/metaclass-boilerplate.rst:2
msgid "metaclass-boilerplate"
msgstr "metaclass-boilerplate"

#: ../../rst/dev_guide/testing/sanity/metaclass-boilerplate.rst:4
msgid "Most Python files should include the following boilerplate at the top of the file, right after the comment header and ``from __future__ import``:"
msgstr "ほとんどの Python ファイルには、ファイルの上部、コメントヘッダーのおよび ``from __future__ import`` の直後に次の boilerplate を含める必要があります。"

#: ../../rst/dev_guide/testing/sanity/metaclass-boilerplate.rst:12
msgid "Python 2 has \"new-style classes\" and \"old-style classes\" whereas Python 3 only has new-style classes. Adding the ``__metaclass__ = type`` boilerplate makes every class defined in that file into a new-style class as well."
msgstr "Python 2 には「新スタイルのクラス」および「旧スタイルのクラス」が使用されますが、Python 3 には新スタイルのクラスのみが使用されます。また、``__metaclass__ = type`` boilerplate を追加すると、そのファイルで定義されているすべてのクラスが新しいスタイルのクラスになります。"

#: ../../rst/dev_guide/testing/sanity/mypy.rst:2
msgid "mypy"
msgstr "mypy"

#: ../../rst/dev_guide/testing/sanity/mypy.rst:4
msgid "The ``mypy`` static type checker is used to check the following code against each Python version supported by the controller:"
msgstr "``mypy`` 静的タイプチェッカーは、コントローラーがサポートする各 Python バージョンに対して以下のコードを確認するために使用されます。"

#: ../../rst/dev_guide/testing/sanity/mypy.rst:6
msgid "``lib/ansible/``"
msgstr "``lib/ansible/``"

#: ../../rst/dev_guide/testing/sanity/mypy.rst:7
msgid "``test/lib/ansible_test/_internal/``"
msgstr "``test/lib/ansible_test/_internal/``"

#: ../../rst/dev_guide/testing/sanity/mypy.rst:9
msgid "Additionally, the following code is checked against Python versions supported only on managed nodes:"
msgstr "また、以下のコードは、管理対象ノードでのみサポートされる Python バージョンに対して確認されます。"

#: ../../rst/dev_guide/testing/sanity/mypy.rst:14
msgid "See https://mypy.readthedocs.io/en/stable/ for additional details."
msgstr "詳細は https://mypy.readthedocs.io/en/stable/ を参照してください。"

#: ../../rst/dev_guide/testing/sanity/no-assert.rst:2
msgid "no-assert"
msgstr "assert は使用しない"

#: ../../rst/dev_guide/testing/sanity/no-assert.rst:4
msgid "Do not use ``assert`` in production Ansible python code. When running Python with optimizations, Python will remove ``assert`` statements, potentially allowing for unexpected behavior throughout the Ansible code base."
msgstr "実稼働環境の Ansible Python コードで ``assert`` を使用しないでください。最適化で Python を実行すると、Python は ``assert`` ステートメントを削除すると、Ansible のコードベース全体で予期しない動作が可能になります。"

#: ../../rst/dev_guide/testing/sanity/no-assert.rst:8
msgid "Instead of using ``assert`` you should utilize simple ``if`` statements, that result in raising an exception. There is a new exception called ``AnsibleAssertionError`` that inherits from ``AnsibleError`` and ``AssertionError``. When possible, utilize a more specific exception than ``AnsibleAssertionError``."
msgstr "``assert`` を使用する代わりに、簡単な ``if`` ステートメントを利用する必要があります。その結果、例外が発生します。``AnsibleError`` および ``AssertionError`` から継承する ``AnsibleAssertionError`` と呼ばれる新しい例外があります。可能であれば、``AnsibleAssertionError`` より具体的な例外を利用してください。"

#: ../../rst/dev_guide/testing/sanity/no-assert.rst:14
msgid "Modules will not have access to ``AnsibleAssertionError`` and should instead raise ``AssertionError``, a more specific exception, or just use ``module.fail_json`` at the failure point."
msgstr "モジュールは ``AnsibleAssertionError`` にアクセスできないため、代わりに ``AssertionError`` を高くすることはできません。あるいは、障害段階で ``module.fail_json`` を使用します。"

#: ../../rst/dev_guide/testing/sanity/no-basestring.rst:2
msgid "no-basestring"
msgstr "basestring は使用しない"

#: ../../rst/dev_guide/testing/sanity/no-basestring.rst:4
msgid "Do not use ``isinstance(s, basestring)`` as basestring has been removed in Python3.  You can import ``string_types``, ``binary_type``, or ``text_type`` from ``ansible.module_utils.six`` and then use ``isinstance(s, string_types)`` or ``isinstance(s, (binary_type, text_type))`` instead."
msgstr "Python3 では ``isinstance(s, basestring)`` をベース文字列から削除しないでください。``string_types``、``binary_type``、または ``text_type`` を ``ansible.module_utils.six`` からインポートしてから、代わりに ``isinstance(s, string_types)`` または ``isinstance(s, (binary_type, text_type))`` を使用できます。"

#: ../../rst/dev_guide/testing/sanity/no-basestring.rst:9
msgid "If this is part of code to convert a string to a particular type, ``ansible.module_utils.common.text.converters`` contains several functions that may be even better for you: ``to_text``, ``to_bytes``, and ``to_native``."
msgstr "これが文字列を特定の型に変換するコードの一部である場合、``ansible.module_utils.common.text.converters`` には、より良い関数がいくつか含まれています (``to_text``、``to_bytes``、および ``to_native``)。"

#: ../../rst/dev_guide/testing/sanity/no-dict-iteritems.rst:2
msgid "no-dict-iteritems"
msgstr "dict-iteritems は使用しない"

#: ../../rst/dev_guide/testing/sanity/no-dict-iteritems.rst:4
msgid "The ``dict.iteritems`` method has been removed in Python 3. There are two recommended alternatives:"
msgstr "この ``dict.iteritems`` メソッドは、Python 3 で削除されました。推奨される代替手段が 2 つあります。"

#: ../../rst/dev_guide/testing/sanity/no-dict-iterkeys.rst:2
msgid "no-dict-iterkeys"
msgstr "dict-iterkeys は使用しない"

#: ../../rst/dev_guide/testing/sanity/no-dict-iterkeys.rst:4
msgid "The ``dict.iterkeys`` method has been removed in Python 3. Use the following instead:"
msgstr "この ``dict.iterkeys`` メソッドは、Python 3 で削除されました。代わりに、以下を使用します。"

#: ../../rst/dev_guide/testing/sanity/no-dict-itervalues.rst:2
msgid "no-dict-itervalues"
msgstr "dict-itervalues は使用しない"

#: ../../rst/dev_guide/testing/sanity/no-dict-itervalues.rst:4
msgid "The ``dict.itervalues`` method has been removed in Python 3. There are two recommended alternatives:"
msgstr "この ``dict.itervalues`` メソッドは、Python 3 で削除されました。推奨される代替手段が 2 つあります。"

#: ../../rst/dev_guide/testing/sanity/no-get-exception.rst:2
msgid "no-get-exception"
msgstr "get-exception は使用しない"

#: ../../rst/dev_guide/testing/sanity/no-get-exception.rst:4
msgid "We created a function, ``ansible.module_utils.pycompat24.get_exception`` to help retrieve exceptions in a manner compatible with Python 2.4 through Python 3.6.  We no longer support Python 2.4 and Python 2.5 so this is extraneous and we want to deprecate the function.  Porting code should look something like this:"
msgstr "Python 2.4 ～ Python 3.6 と互換性がある方法で例外を取得するのに役立つ関数 ``ansible.module_utils.pycompat24.get_exception`` を作成しました。Python 2.4 および Python 2.5 はサポートされなくなったため、これは外部のものであり、この関数を廃止する必要があります。移植コードは、以下のようになります。"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:2
msgid "no-illegal-filenames"
msgstr "不正なファイル名は使用しない"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:4
msgid "Files and directories should not contain illegal characters or names so that Ansible can be checked out on any Operating System."
msgstr "ファイルとディレクトリーには、Ansible をどのオペレーティングシステムでもチェックアウトできるように、不正な文字や名前は使用しないでください。"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:8
msgid "Illegal Characters"
msgstr "不正な文字"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:10
msgid "The following characters are not allowed to be used in any part of the file or directory name;"
msgstr "以下の文字は、ファイルまたはディレクトリーの名前には使用できません。"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:13
msgid "``<``"
msgstr "``<``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:14
msgid "``>``"
msgstr "``>``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:15
msgid "``:``"
msgstr "``:``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:16
msgid "``\"``"
msgstr "``\"``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:17
msgid "``/``"
msgstr "``/``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:18
msgid "``\\``"
msgstr "``\\``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:19
msgid "``|``"
msgstr "``|``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:20
msgid "``?``"
msgstr "``?``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:21
msgid "``*``"
msgstr "``*``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:22
msgid "Any characters whose integer representations are in the range from 0 through to 31 like ``\\n``"
msgstr "整数表示が 0 から 31 までの文字 (例: ``\\n"
"``)"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:24
msgid "The following characters are not allowed to be used as the last character of a file or directory;"
msgstr "次の文字は、ファイルまたはディレクトリーの最後の文字には使用できません。"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:27
msgid "``.``"
msgstr "``.``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:28
msgid "``\" \"`` (just the space character)"
msgstr "``\" \"`` (空白文字のみ)"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:31
msgid "Illegal Names"
msgstr "不正な名前"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:33
msgid "The following names are not allowed to be used as the name of a file or directory excluding the extension;"
msgstr "以下の名前は、拡張子を除いてファイルまたはディレクトリーの名前として使用することはできません。"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:36
msgid "``CON``"
msgstr "``CON``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:37
msgid "``PRN``"
msgstr "``PRN``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:38
msgid "``AUX``"
msgstr "``AUX``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:39
msgid "``NUL``"
msgstr "``NUL``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:40
msgid "``COM1``"
msgstr "``COM1``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:41
msgid "``COM2``"
msgstr "``COM2``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:42
msgid "``COM3``"
msgstr "``COM3``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:43
msgid "``COM4``"
msgstr "``COM4``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:44
msgid "``COM5``"
msgstr "``COM5``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:45
msgid "``COM6``"
msgstr "``COM6``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:46
msgid "``COM7``"
msgstr "``COM7``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:47
msgid "``COM8``"
msgstr "``COM8``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:48
msgid "``COM9``"
msgstr "``COM9``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:49
msgid "``LPT1``"
msgstr "``LPT1``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:50
msgid "``LPT2``"
msgstr "``LPT2``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:51
msgid "``LPT3``"
msgstr "``LPT3``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:52
msgid "``LPT4``"
msgstr "``LPT4``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:53
msgid "``LPT5``"
msgstr "``LPT5``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:54
msgid "``LPT6``"
msgstr "``LPT6``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:55
msgid "``LPT7``"
msgstr "``LPT7``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:56
msgid "``LPT8``"
msgstr "``LPT8``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:57
msgid "``LPT9``"
msgstr "``LPT9``"

#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:59
msgid "For example, the file ``folder/COM1``, ``folder/COM1.txt`` are illegal but ``folder/COM1-file`` or ``folder/COM1-file.txt`` is allowed."
msgstr "たとえば、``folder/COM1`` ファイルまたは ``folder/COM1.txt`` ファイルは許可されませんが、``folder/COM1-file`` ファイルまたは ``folder/COM1-file.txt`` ファイルは許可されます。"

#: ../../rst/dev_guide/testing/sanity/no-main-display.rst:2
msgid "no-main-display"
msgstr "main-display は使用しない"

#: ../../rst/dev_guide/testing/sanity/no-main-display.rst:4
msgid "As of Ansible 2.8, ``Display`` should no longer be imported from ``__main__``."
msgstr "Ansible 2.8 以降、``Display`` は ``__main__`` からインポートしないようにしてください。"

#: ../../rst/dev_guide/testing/sanity/no-main-display.rst:6
msgid "``Display`` is now a singleton and should be utilized like the following:"
msgstr "``Display`` はシングルトンで、以下のように使用する必要があります。"

#: ../../rst/dev_guide/testing/sanity/no-main-display.rst:13
msgid "There is no longer a need to attempt ``from __main__ import display`` inside a ``try/except`` block."
msgstr "``try/except`` ブロック内で ``from __main__ import display`` を試行する必要がなくなりました。"

#: ../../rst/dev_guide/testing/sanity/no-smart-quotes.rst:2
msgid "no-smart-quotes"
msgstr "スマート引用符は使用しない"

#: ../../rst/dev_guide/testing/sanity/no-smart-quotes.rst:4
msgid "Smart quotes (``”“‘’``) should not be used.  Use plain ascii quotes (``\"'``) instead."
msgstr "スマート引用符 (``”“‘’``) は使用しないでください。代わりに、標準の ascii 引用符 (``\"'``) を使用します。"

#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:4
msgid "no-tests-as-filters"
msgstr "テストをフィルターとして使用しない"

#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:6
msgid "Using Ansible provided Jinja2 tests as filters will be removed in Ansible 2.9."
msgstr "Ansible が提供する Jinja2 テストをフィルターとして使用することは、Ansible 2.9 で削除されます。"

#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:8
msgid "Prior to Ansible 2.5, Jinja2 tests included within Ansible were most often used as filters. The large difference in use is that filters are referenced as ``variable | filter_name`` while Jinja2 tests are referenced as ``variable is test_name``."
msgstr "Ansible 2.5 以前は、Ansible に含まれる Jinja2 テストは、ほとんどがフィルターとして使用されていました。使用方法の大きな違いは、フィルターは ``variable | filter_name`` として参照されるのに対し、Jinja2 テストは ``variable is test_name`` として参照されることです。"

#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:10
msgid "Jinja2 tests are used for comparisons, whereas filters are used for data manipulation, and have different applications in Jinja2. This change is to help differentiate the concepts for a better understanding of Jinja2, and where each can be appropriately used."
msgstr "Jinja2 テストは比較のために使用され、フィルターはデータ操作のために使用され、Jinja2 でそれぞれ用途が異なります。この変更は、Jinja2 の理解を深めるために概念を区別し、それぞれを適切に使用できるようにするためのものです。"

#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:12
msgid "As of Ansible 2.5 using an Ansible provided Jinja2 test with filter syntax will display a deprecation error."
msgstr "Ansible 2.5 以降では、Ansible が提供する Jinja2 テストをフィルター構文で使用すると、非推奨エラーが表示されます。"

#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:4
msgid "no-underscore-variable"
msgstr "no-underscore-variable"

#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:6
msgid "In the future, Ansible may use the identifier ``_`` to internationalize its message strings.  To be ready for that, we need to make sure that there are no conflicting identifiers defined in the code base."
msgstr "今後、Ansible は、識別子 ``_`` を使用して、メッセージ文字列を国際化することができます。そのためには、コードベースで定義されている識別子が競合しないようにする必要があります。"

#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:10
msgid "In common practice, ``_`` is frequently used as a dummy variable (a variable to receive a value from a function where the value is useless and never used). In Ansible, we're using the identifier ``dummy`` for this purpose instead."
msgstr "一般的な慣行では、``_`` は、ダミー変数 (値が役に立たず、使用されない関数から値を受け取る変数) として頻繁に使用されます。Ansibleでは、代わりにこの目的のために識別子 ``dummy`` を使用しています。"

#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:14
msgid "Example of unfixed code:"
msgstr "未修正コードの例:"

#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:23
msgid "Example of fixed code:"
msgstr "修正したコードの例:"

#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:2
msgid "no-unicode_literals"
msgstr "no-unicode_literals"

#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:4
msgid "The use of :code:`from __future__ import unicode_literals` has been deemed an anti-pattern.  The problems with it are:"
msgstr ":code:`from __future__ import unicode_literals` の使用はアンチパターンと見なされます。その問題は次のとおりです。"

#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:7
msgid "It makes it so one can't jump into the middle of a file and know whether a bare literal string is a byte string or text string.  The programmer has to first check the top of the file to see if the import is there."
msgstr "これにより、ファイルの途中にジャンプして、裸のリテラル文字列がバイト文字列なのかテキスト文字列なのかを知ることができなくなります。プログラマーは、最初にファイルの先頭をチェックして、インポートが存在するかどうかを確認する必要があります。"

#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:10
msgid "It removes the ability to define native strings (a string which should be a byte string on python2 and a text string on python3) via a string literal."
msgstr "これにより、文字列リテラルを介してネイティブ文字列 (python2 ではバイト文字列、python3 ではテキスト文字列である必要がある文字列) を定義する機能が削除されます。"

#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:12
msgid "It makes for more context switching.  A programmer could be reading one file which has `unicode_literals` and know that bare string literals are text strings but then switch to another file (perhaps tracing program execution into a third party library) and have to switch their understanding of what bare string literals are."
msgstr "そのため、コンテキストの切り替えが多くなります。プログラマーは、`unicode_literals` を含むあるファイルを読み込んでいて、裸の文字列リテラルがテキスト文字列であることを理解ｓていますが、その後、別のファイル (おそらくサードパーティーのライブラリーへのプログラム実行の追跡) に替えて、裸の文字列リテラルが何であるかの理解に切り替えなければなりません。"

#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:2
msgid "no-unwanted-files"
msgstr "不要なファイルは使用しない"

#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:4
msgid "Specific file types are allowed in certain directories:"
msgstr "特定のファイルタイプは、特定のディレクトリーで許可されます。"

#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:6
msgid "``lib`` - All content must reside in the ``lib/ansible`` directory."
msgstr "``lib`` - すべてのコンテンツは ``lib/ansible`` ディレクトリーに置く必要があります。"

#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:8
msgid "``lib/ansible`` - Only source code with one of the following extensions is allowed:"
msgstr "``lib/ansible`` - 以下の拡張機能のいずれかを持つソースコードのみが許可されます。"

#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:10
msgid "``*.cs`` - C#"
msgstr "``*.cs`` - C#"

#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:11
msgid "``*.ps1`` - PowerShell"
msgstr "``*.ps1`` - PowerShell"

#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:12
msgid "``*.psm1`` - PowerShell"
msgstr "``*.psm1`` - PowerShell"

#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:13
msgid "``*.py`` - Python"
msgstr "``*.py`` - Python"

#: ../../rst/dev_guide/testing/sanity/no-wildcard-import.rst:4
msgid "no-wildcard-import"
msgstr "ワイルドカードの import は使用しない"

#: ../../rst/dev_guide/testing/sanity/no-wildcard-import.rst:6
msgid "Using :code:`import *` is a bad habit which pollutes your namespace, hinders debugging, and interferes with static analysis of code.  For those reasons, we do want to limit the use of :code:`import *` in the ansible code.  Change our code to import the specific names that you need instead."
msgstr ":code:`import *` を使用することは、名前空間を汚染し、デバッグを妨げ、コードの静的分析を妨げる悪い習慣です。これらの理由から、Ansible コードで :code:`import *` の使用を制限します。代わりに、必要な特定の名前をインポートするようにコードを変更してください。"

#: ../../rst/dev_guide/testing/sanity/no-wildcard-import.rst:11
msgid "Examples of unfixed code:"
msgstr "未修正コードの例:"

#: ../../rst/dev_guide/testing/sanity/no-wildcard-import.rst:22
msgid "Examples of fixed code:"
msgstr "修正されたコードの例:"

#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:2
msgid "obsolete-files"
msgstr "陳腐化したファイル"

#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:4
msgid "Directories in the Ansible source tree are sometimes made obsolete. Files should not exist in these directories. The new location (if any) is dependent on which directory has been made obsolete."
msgstr "Ansible ソースツリー内のディレクトリーは廃止されることがあります。ファイルは、このディレクトリーに存在すべきではありません。新しい場所が存在する場合は、どのディレクトリーが廃止されたかに依存しています。"

#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:8
msgid "Below are some of the obsolete directories and their new locations:"
msgstr "古いディレクトリーとその新しい場所を以下に示します。"

#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:10
msgid "All of ``test/runner/`` is now under ``test/lib/ansible_test/`` instead. The organization of files in the new directory has changed."
msgstr "すべての ``test/runner/`` は、現在、代わりに ``test/lib/ansible_test/`` にあります。新しいディレクトリーのファイルの編成が変更になりました。"

#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:11
msgid "Most subdirectories of ``test/sanity/`` (with some exceptions) are now under ``test/lib/ansible_test/_util/controller/sanity/`` instead."
msgstr "``test/sanity/``のサブディレクトリーのほとんどは (例外あり) 、代わりに ``test/lib/ansible_test/_util/controller/sanity/`` の下にあります。"

#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:13
msgid "This error occurs most frequently for open pull requests which add or modify files in directories which are now obsolete. Make sure the branch you are working from is current so that changes can be made in the correct location."
msgstr "このエラーは、現在古くなったディレクトリーのファイルを追加または変更するオープンなプル要求に対して最も頻繁に発生します。正しい場所で変更できるように、作業しているブランチが現在の状態であることを確認します。"

#: ../../rst/dev_guide/testing/sanity/package-data.rst:2
msgid "package-data"
msgstr "package-data"

#: ../../rst/dev_guide/testing/sanity/package-data.rst:4
msgid "Verifies that the combination of ``MANIFEST.in`` and ``package_data`` from ``setup.py`` properly installs data files from within ``lib/ansible``"
msgstr "``setup.py`` から ``MANIFEST.in`` と ``package_data`` を組み合わせて、``lib/ansible`` 内からデータファイルが適切にインストールされていることを確認します。"

#: ../../rst/dev_guide/testing/sanity/pep8.rst:2
msgid "pep8"
msgstr "pep8"

#: ../../rst/dev_guide/testing/sanity/pep8.rst:4
msgid "Python static analysis for PEP 8 style guideline compliance."
msgstr "PEP 8 スタイルのガイドラインコンプライアンスに対する Python 静的分析です。"

#: ../../rst/dev_guide/testing/sanity/pep8.rst:6
msgid "See :ref:`testing_pep8` for more information."
msgstr "詳細は、「:ref:`testing_pep8`」を参照してください。"

#: ../../rst/dev_guide/testing/sanity/pslint.rst:2
msgid "pslint"
msgstr "pslint"

#: ../../rst/dev_guide/testing/sanity/pslint.rst:4
msgid "PowerShell static analysis for common programming errors using `PSScriptAnalyzer <https://github.com/PowerShell/PSScriptAnalyzer/>`_."
msgstr "`PSScriptAnalyzer <https://github.com/PowerShell/PSScriptAnalyzer/>`_ を使用した一般的なプログラミングエラーに関する PowerShell の静的な分析です。"

#: ../../rst/dev_guide/testing/sanity/pylint.rst:2
msgid "pylint"
msgstr "pylint"

#: ../../rst/dev_guide/testing/sanity/pylint-ansible-test.rst:6
#: ../../rst/dev_guide/testing/sanity/pylint.rst:4
msgid "Python static analysis for common programming errors."
msgstr "一般的なプログラミングエラーに対する Python の静的分析です。"

#: ../../rst/dev_guide/testing/sanity/pylint-ansible-test.rst:4
msgid "pylint-ansible-test"
msgstr "pylint-ansible-test"

#: ../../rst/dev_guide/testing/sanity/pylint-ansible-test.rst:8
msgid "A more strict set of rules applied to ``ansible-test``."
msgstr "``ansible-test`` に適用されるより厳密なルールセット"

#: ../../rst/dev_guide/testing/sanity/release-names.rst:2
msgid "Release names"
msgstr "リリース名"

#: ../../rst/dev_guide/testing/sanity/release-names.rst:4
msgid "Verifies that the most recent release name has been added to ``./github/RELEASE_NAMES.yml``"
msgstr "最新のリリース名が ``./github/RELEASE_NAMES.yml`` に追加されたことを確認します。"

#: ../../rst/dev_guide/testing/sanity/replace-urlopen.rst:2
msgid "replace-urlopen"
msgstr "replace-urlopen"

#: ../../rst/dev_guide/testing/sanity/replace-urlopen.rst:4
msgid "Use ``open_url`` from ``module_utils`` instead of ``urlopen``."
msgstr "``urlopen`` の代わりに ``module_utils`` から ``open_url`` を使用します。"

#: ../../rst/dev_guide/testing/sanity/required-and-default-attributes.rst:2
msgid "required-and-default-attributes"
msgstr "required-and-default-attributes"

#: ../../rst/dev_guide/testing/sanity/required-and-default-attributes.rst:4
msgid "Use only one of ``default`` or ``required`` with ``FieldAttribute``."
msgstr "``default`` または ``required`` の 1 つのみを ``FieldAttribute`` で使用します。"

#: ../../rst/dev_guide/testing/sanity/rstcheck.rst:2
msgid "rstcheck"
msgstr "rstcheck"

#: ../../rst/dev_guide/testing/sanity/rstcheck.rst:4
msgid "Check reStructuredText files for syntax and formatting issues."
msgstr "構文およびフォーマットに関する問題は、eStructuredTex ファイルを確認してください。"

#: ../../rst/dev_guide/testing/sanity/runtime-metadata.rst:2
msgid "runtime-metadata.yml"
msgstr "runtime-metadata.yml"

#: ../../rst/dev_guide/testing/sanity/runtime-metadata.rst:4
msgid "Validates the schema for:"
msgstr "スキーマを検証します。"

#: ../../rst/dev_guide/testing/sanity/runtime-metadata.rst:6
msgid "ansible-core's ``lib/ansible/config/ansible_builtin_runtime.yml``"
msgstr "ansible-core の ``lib/ansible/config/ansible_builtin_runtime.yml``"

#: ../../rst/dev_guide/testing/sanity/runtime-metadata.rst:7
msgid "collection's ``meta/runtime.yml``"
msgstr "コレクションの ``meta/runtime.yml``"

#: ../../rst/dev_guide/testing/sanity/sanity-docs.rst:2
msgid "sanity-docs"
msgstr "sanity-docs"

#: ../../rst/dev_guide/testing/sanity/sanity-docs.rst:4
msgid "Documentation for each ``ansible-test sanity`` test is required."
msgstr "各 ``ansible-test sanity`` テスト用のドキュメントが必要です。"

#: ../../rst/dev_guide/testing/sanity/shebang.rst:2
msgid "shebang"
msgstr "shebang"

#: ../../rst/dev_guide/testing/sanity/shebang.rst:4
msgid "Most executable files should only use one of the following shebangs:"
msgstr "実行ファイルのほとんどは、以下のいずれかの shebang のみを使用する必要があります。"

#: ../../rst/dev_guide/testing/sanity/shebang.rst:6
msgid "``#!/bin/sh``"
msgstr "``#!/bin/sh``"

#: ../../rst/dev_guide/testing/sanity/shebang.rst:7
msgid "``#!/bin/bash``"
msgstr "``#!/bin/bash``"

#: ../../rst/dev_guide/testing/sanity/shebang.rst:8
msgid "``#!/usr/bin/make``"
msgstr "``#!/usr/bin/make``"

#: ../../rst/dev_guide/testing/sanity/shebang.rst:9
msgid "``#!/usr/bin/env python``"
msgstr "``#!/usr/bin/env python``"

#: ../../rst/dev_guide/testing/sanity/shebang.rst:10
msgid "``#!/usr/bin/env bash``"
msgstr "``#!/usr/bin/env bash``"

#: ../../rst/dev_guide/testing/sanity/shebang.rst:12
msgid "NOTE: For ``#!/bin/bash``, any of the options ``eux`` may also be used, such as ``#!/bin/bash -eux``."
msgstr "注記: ``#!/bin/bash`` の場合は、いずれのオプションの ``eux`` も使用できます (``#!/bin/bash -eux`` など)。"

#: ../../rst/dev_guide/testing/sanity/shebang.rst:14
msgid "This does not apply to Ansible modules, which should not be executable and must always use ``#!/usr/bin/python``."
msgstr "これは Ansible モジュールには適用されません。これは実行可能ではなく、``#!/usr/bin/python`` を常に使用する必要があります。"

#: ../../rst/dev_guide/testing/sanity/shebang.rst:16
msgid "Some exceptions are permitted. Ask if you have questions."
msgstr "一部の例外が許可されます。ご質問がある場合はお問い合わせください。"

#: ../../rst/dev_guide/testing/sanity/shellcheck.rst:2
msgid "shellcheck"
msgstr "shellcheck"

#: ../../rst/dev_guide/testing/sanity/shellcheck.rst:4
msgid "Static code analysis for shell scripts using the excellent `shellcheck <https://www.shellcheck.net/>`_ tool."
msgstr "優れた `shellcheck <https://www.shellcheck.net/>`_ ツールを使用してシェルスクリプトの静的コード分析。"

#: ../../rst/dev_guide/testing/sanity/symlinks.rst:2
msgid "symlinks"
msgstr "symlinks"

#: ../../rst/dev_guide/testing/sanity/symlinks.rst:4
msgid "Symbolic links are only permitted for files that exist to ensure proper tarball generation during a release."
msgstr "シンボリックリンクは、リリース中に適切な tarball 生成を保証するファイルにのみ許可されます。"

#: ../../rst/dev_guide/testing/sanity/symlinks.rst:6
msgid "If other types of symlinks are needed for tests they must be created as part of the test."
msgstr "テストに他のシンボリックリンクが必要な場合は、テストの一部として作成する必要があります。"

#: ../../rst/dev_guide/testing/sanity/test-constraints.rst:2
msgid "test-constraints"
msgstr "test-constraints"

#: ../../rst/dev_guide/testing/sanity/test-constraints.rst:4
msgid "Constraints for test requirements should be in ``test/lib/ansible_test/_data/requirements/constraints.txt``."
msgstr "テスト要件の制約は ``test/lib/ansible_test/_data/requirements/constraints.txt`` に保存されている必要があります。"

#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:4
msgid "update-bundled"
msgstr "update-bundled"

#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:6
msgid "Check whether any of our known bundled code needs to be updated for a new upstream release."
msgstr "既知のバンドルされたコードが新しいアップストリームリリース用に更新する必要があるかどうかを確認します。"

#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:8
msgid "This test can error in the following ways:"
msgstr "このテストは以下の方法でエラーが発生する可能性があります。"

#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:10
msgid "The bundled code is out of date with regard to the latest release on pypi.  Update the code to the new version and update the version in _BUNDLED_METADATA to solve this."
msgstr "バンドルされたコードは pypi の最新リリースに関して古くなっています。コードを新しいバージョンに更新し、_BUNDLED_METADATA でバージョンを更新してこれを解決します。"

#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:13
msgid "The code is lacking a _BUNDLED_METADATA variable.  This typically happens when a bundled version is updated and we forget to add a _BUNDLED_METADATA variable to the updated file.  Once that is added, this error should go away."
msgstr "このコードには _BUNDLED_METADATA 変数がありません。これは通常、バンドルバージョンが更新され、更新されたファイルに _BUNDLED_METADATA 変数を追加し忘れた場合に発生します。それが追加されると、このエラーはなくなるはずです。"

#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:17
msgid "A file has a _BUNDLED_METADATA variable but the file isn't specified in :file:`test/sanity/code-smell/update-bundled.py`.  This typically happens when a new bundled library is added.  Add the file to the `get_bundled_libs()` function in the `update-bundled.py` test script to solve this error."
msgstr "ファイルには、_BUNDLED_METADATA 変数がありますが、そのファイルは :file:`test/sanity/code-smell/update-bundled.py` で指定されていません。これは通常、新しいバンドルライブラリーが追加されたときに発生します。このエラーを解決するために、`update-bundled.py` テストスクリプトの `get_bundled_libs()` 関数にファイルを追加します。"

#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:22
msgid "_BUNDLED_METADATA has the following fields:"
msgstr "_BUNDLED_METADATA には以下のフィールドがあります。"

#: ../../rst/dev_guide/testing/sanity/update-bundled.rst
msgid "pypi_name"
msgstr "pypi_name"

#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:24
msgid "Name of the bundled package on pypi"
msgstr "pypi でバンドルされたパッケージの名前"

#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:26
msgid "Version of the package that we are including here"
msgstr "ここに含めるパッケージのバージョン"

#: ../../rst/dev_guide/testing/sanity/update-bundled.rst
msgid "version_constraints"
msgstr "version_constraints"

#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:28
msgid "Optional PEP440 specifier for the version range that we are bundling. Currently, the only valid use of this is to follow a version that is compatible with the Python stdlib when newer versions of the pypi package implement a new API."
msgstr "バンドルするバージョン範囲の任意の PEP440 指定子。現在、これの唯一の有効な使用法は、新しいバージョンの pypi パッケージが新しい API を実装するときに、Python stdlib と互換性のあるバージョンに従うことです。"

#: ../../rst/dev_guide/testing/sanity/use-argspec-type-path.rst:2
msgid "use-argspec-type-path"
msgstr "use-argspec-type-path"

#: ../../rst/dev_guide/testing/sanity/use-argspec-type-path.rst:4
msgid "The AnsibleModule argument_spec knows of several types beyond the standard python types.  One of these is ``path``.  When used, type ``path`` ensures that an argument is a string and expands any shell variables and tilde characters."
msgstr "AnsibleModule の argument_spec は、標準の python タイプ以外の複数のタイプを認識します。これらのいずれかが ``path`` になります。使用すると、``path`` と入力して、引数が文字列で、シェル変数とチルダ文字を拡張するようにします。"

#: ../../rst/dev_guide/testing/sanity/use-argspec-type-path.rst:8
msgid "This test looks for use of :func:`os.path.expanduser <python:os.path.expanduser>` in modules.  When found, it tells the user to replace it with ``type='path'`` in the module's argument_spec or list it as a false positive in the test."
msgstr "このテストでは、モジュールで :func:`os.path.expanduser <python:os.path.expanduser>` の使用を探します。見つかった場合は、モジュールの argument_spec で ``type='path'`` に置き換えるか、テストで誤検出として一覧に挙げられます。"

#: ../../rst/dev_guide/testing/sanity/use-compat-six.rst:2
msgid "use-compat-six"
msgstr "use-compat-six"

#: ../../rst/dev_guide/testing/sanity/use-compat-six.rst:4
msgid "Use ``six`` from ``module_utils`` instead of ``six``."
msgstr "``six`` の代わりに ``module_utils`` から ``six`` を使用します。"

#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:2
#: ../../rst/dev_guide/testing_validate-modules.rst:7
msgid "validate-modules"
msgstr "validate-modules"

#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:4
msgid "Analyze modules for common issues in code and documentation."
msgstr "コードおよびドキュメントの一般的な問題についてモジュールを分析します。"

#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:6
msgid "See :ref:`testing_validate-modules` for more information."
msgstr "詳細は、「:ref:`testing_validate-modules`」を参照してください。"

#: ../../rst/dev_guide/testing/sanity/yamllint.rst:2
msgid "yamllint"
msgstr "yamllint"

#: ../../rst/dev_guide/testing/sanity/yamllint.rst:4
msgid "Check YAML files for syntax and formatting issues."
msgstr "YAML ファイルにおける構文およびフォーマットの問題を確認します。"

#: ../../rst/dev_guide/testing_compile.rst:7
msgid "Compile Tests"
msgstr "コンパイルテスト"

#: ../../rst/dev_guide/testing_compile.rst:12
#: ../../rst/dev_guide/testing_httptester.rst:10
msgid "Overview"
msgstr "概要"

#: ../../rst/dev_guide/testing_compile.rst:14
msgid "Compile tests check source files for valid syntax on all supported python versions:"
msgstr "コンパイルテストでは、サポートされているすべての python バージョンで、ソースファイルの構文が有効かどうかを確認します。"

#: ../../rst/dev_guide/testing_compile.rst:16
msgid "2.4 (Ansible 2.3 only)"
msgstr "2.4 (Ansible 2.3 のみ)"

#: ../../rst/dev_guide/testing_compile.rst:17
msgid "2.6"
msgstr "2.6"

#: ../../rst/dev_guide/testing_compile.rst:18
msgid "2.7"
msgstr "2.7"

#: ../../rst/dev_guide/testing_compile.rst:19
msgid "3.5"
msgstr "3.5"

#: ../../rst/dev_guide/testing_compile.rst:20
msgid "3.6"
msgstr "3.6"

#: ../../rst/dev_guide/testing_compile.rst:21
msgid "3.7"
msgstr "3.7"

#: ../../rst/dev_guide/testing_compile.rst:22
msgid "3.8"
msgstr "3.8"

#: ../../rst/dev_guide/testing_compile.rst:23
msgid "3.9"
msgstr "3.9"

#: ../../rst/dev_guide/testing_compile.rst:25
msgid "NOTE: In Ansible 2.4 and earlier the compile test was provided by a dedicated sub-command ``ansible-test compile`` instead of a sanity test using ``ansible-test sanity --test compile``."
msgstr "注記: Ansible 2.4 以前では、``ansible-test sanity --test compile`` を使用する健全性テストの代わりに、コンパイルテストが専用のサブコマンド ``ansible-test compile`` によって提供されていました。"

#: ../../rst/dev_guide/testing_compile.rst:28
msgid "Running compile tests locally"
msgstr "ローカルでのコンパイルテストの実行"

#: ../../rst/dev_guide/testing_compile.rst:30
msgid "Compile tests can be run across the whole code base by doing:"
msgstr "コンパイルテストを実行するには、次のように、コードベース全体でテストを実行できます。"

#: ../../rst/dev_guide/testing_compile.rst:38
#: ../../rst/dev_guide/testing_units.rst:38
msgid "Against a single file by doing:"
msgstr "1 つのファイルに対して以下を行います。"

#: ../../rst/dev_guide/testing_compile.rst:44
#: ../../rst/dev_guide/testing_units.rst:44
msgid "Or against a specific Python version by doing:"
msgstr "または、特定の Python バージョンに対して以下を実行します。"

#: ../../rst/dev_guide/testing_compile.rst:50
msgid "For advanced usage see the help:"
msgstr "高度な使用方法は、ヘルプを参照してください。"

#: ../../rst/dev_guide/testing_compile.rst:58
#: ../../rst/dev_guide/testing_units.rst:68
msgid "Installing dependencies"
msgstr "依存関係のインストール"

#: ../../rst/dev_guide/testing_compile.rst:60
msgid "``ansible-test`` has a number of dependencies , for ``compile`` tests we suggest running the tests with ``--local``, which is the default"
msgstr "``ansible-test`` にはいくつかの依存関係があります。``compile`` テストでは、デフォルトである ``--local`` を使用してテストを実行することが推奨されます。"

#: ../../rst/dev_guide/testing_compile.rst:62
msgid "The dependencies can be installed using the ``--requirements`` argument. For example:"
msgstr "依存関係は、``--requirements`` 引数を使用してインストールできます。以下に例を示します。"

#: ../../rst/dev_guide/testing_compile.rst:70
msgid "The full list of requirements can be found at `test/lib/ansible_test/_data/requirements <https://github.com/ansible/ansible/tree/devel/test/lib/ansible_test/_data/requirements>`_. Requirements files are named after their respective commands. See also the `constraints <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_data/requirements/constraints.txt>`_ applicable to all commands."
msgstr "要件の一覧は `test/lib/ansible_test/_data/requirements <https://github.com/ansible/ansible/tree/devel/test/lib/ansible_test/_data/requirements>`_ に記載されています。要件ファイルには、各コマンドにちなんで名前が付けられています。全コマンドに適用される `制約 <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_data/requirements/constraints.txt>`_ も参照してください。"

#: ../../rst/dev_guide/testing_compile.rst:74
msgid "Extending compile tests"
msgstr "コンパイルテストの拡張"

#: ../../rst/dev_guide/testing_compile.rst:76
msgid "If you believe changes are needed to the compile tests please add a comment on the `Testing Working Group Agenda <https://github.com/ansible/community/blob/main/meetings/README.md>`_ so it can be discussed."
msgstr "コンパイルテストに変更が必要な場合は、`Testing Working Group Agenda <https://github.com/ansible/community/blob/main/meetings/README.md>`_ にコメントを追加してください。その内容について話し合うことができます。"

#: ../../rst/dev_guide/testing_documentation.rst:9
msgid "Before you submit a module for inclusion in the main Ansible repo, you must test your module documentation for correct HTML rendering and to ensure that the argspec matches the documentation in your Python file. The community pages offer more information on :ref:`testing reStructuredText documentation <testing_documentation_locally>`."
msgstr "メインの Ansible リポジトリーに組み込むモジュールを送信する前に、正しい HTML レンダリングついてモジュールドキュメントをテストする必要があります。また、argspec が Python ファイルのドキュメントと一致することを確認する必要があります。コミュニティーページでは、「:ref:`reStructuredText ドキュメントのテスト <testing_documentation_locally>`」の詳細が提供されています。"

#: ../../rst/dev_guide/testing_documentation.rst:11
msgid "To check the HTML output of your module documentation:"
msgstr "モジュールドキュメントの HTML 出力を確認するには、次のコマンドを実行します。"

#: ../../rst/dev_guide/testing_documentation.rst:13
msgid "Ensure working :ref:`development environment <environment_setup>`."
msgstr ":ref:`開発環境 <environment_setup>` が稼働していることを確認します。"

#: ../../rst/dev_guide/testing_documentation.rst:14
#: ../../rst/dev_guide/testing_documentation.rst:28
msgid "Install required Python packages (drop '--user' in venv/virtualenv):"
msgstr "必要な Python パッケージをインストールします (venv/virtualenv に「--user」をドロップします)。"

#: ../../rst/dev_guide/testing_documentation.rst:21
msgid "Ensure your module is in the correct directory: ``lib/ansible/modules/$CATEGORY/mymodule.py``."
msgstr "モジュールが正しいディレクトリー (``lib/ansible/modules/$CATEGORY/mymodule.py``) にあることを確認します。"

#: ../../rst/dev_guide/testing_documentation.rst:22
msgid "Build HTML from your module documentation: ``MODULES=mymodule make webdocs``."
msgstr "モジュールドキュメント ``MODULES=mymodule make webdocs`` から HTML を構築します。"

#: ../../rst/dev_guide/testing_documentation.rst:23
msgid "To build the HTML documentation for multiple modules, use a comma-separated list of module names: ``MODULES=mymodule,mymodule2 make webdocs``."
msgstr "複数のモジュールの HTML ドキュメントを作成するには、モジュール名のコンマ区切りリストを使用します (``MODULES=mymodule,mymodule2 make webdocs``)。"

#: ../../rst/dev_guide/testing_documentation.rst:24
msgid "View the HTML page at ``file:///path/to/docs/docsite/_build/html/modules/mymodule_module.html``."
msgstr "``file:///path/to/docs/docsite/_build/html/modules/mymodule_module.html`` で HTML ページを表示します。"

#: ../../rst/dev_guide/testing_documentation.rst:26
msgid "To ensure that your module documentation matches your ``argument_spec``:"
msgstr "モジュールのドキュメントが ``argument_spec`` と適合するようにするには、以下を行います。"

#: ../../rst/dev_guide/testing_documentation.rst:34
msgid "run the ``validate-modules`` test::"
msgstr "``validate-modules`` テストを実行します。"

#: ../../rst/dev_guide/testing_httptester.rst:5
msgid "httptester"
msgstr "httptester"

#: ../../rst/dev_guide/testing_httptester.rst:12
msgid "``httptester`` is a docker container used to host certain resources required by :ref:`testing_integration`. This is to avoid CI tests requiring external resources (such as git or package repos) which, if temporarily unavailable, would cause tests to fail."
msgstr "``httptester`` は、:ref:`testing_integration` で必要な特定のリソースをホストするのに使用される docker コンテナーです。これにより、(git やパッケージリポジトリーなどの) 外部リソースを必要とする CI テストが回避され、一時的に利用できなくなるとテストが失敗します。"

#: ../../rst/dev_guide/testing_httptester.rst:14
msgid "HTTP Testing endpoint which provides the following capabilities:"
msgstr "以下の機能を提供する HTTP テストエンドポイントです。"

#: ../../rst/dev_guide/testing_httptester.rst:16
msgid "httpbin"
msgstr "httpbin"

#: ../../rst/dev_guide/testing_httptester.rst:17
msgid "nginx"
msgstr "nginx"

#: ../../rst/dev_guide/testing_httptester.rst:18
msgid "SSL"
msgstr "SSL"

#: ../../rst/dev_guide/testing_httptester.rst:19
msgid "SNI"
msgstr "SNI"

#: ../../rst/dev_guide/testing_httptester.rst:20
msgid "Negotiate Authentication"
msgstr "認証のネゴシエート"

#: ../../rst/dev_guide/testing_httptester.rst:23
msgid "Source files can be found in the `http-test-container <https://github.com/ansible/http-test-container>`_ repository."
msgstr "ソースファイルは `http-test-container <https://github.com/ansible/http-test-container>`_ リポジトリーにあります。"

#: ../../rst/dev_guide/testing_httptester.rst:26
msgid "Extending httptester"
msgstr "httptester の拡張"

#: ../../rst/dev_guide/testing_httptester.rst:28
msgid "If you have sometime to improve ``httptester`` please add a comment on the `Testing Working Group Agenda <https://github.com/ansible/community/blob/main/meetings/README.md>`_ to avoid duplicated effort."
msgstr "``httptester`` を改善するタイミングがある場合は、重複作業を回避するために、`Testing Working Group Agenda <https://github.com/ansible/community/blob/main/meetings/README.md>`_ にコメントを追加します。"

#: ../../rst/dev_guide/testing_integration.rst:11
msgid "The Ansible integration Test system."
msgstr "Ansible 統合テストシステム。"

#: ../../rst/dev_guide/testing_integration.rst:13
msgid "Tests for playbooks, by playbooks."
msgstr "Playbook による Playbook のテスト"

#: ../../rst/dev_guide/testing_integration.rst:15
msgid "Some tests may require credentials.  Credentials may be specified with `credentials.yml`."
msgstr "テストによっては認証情報が必要になる場合があります。認証情報は `credentials.yml` で指定できます。"

#: ../../rst/dev_guide/testing_integration.rst:17
msgid "Some tests may require root."
msgstr "テストによっては root が必要になる場合があります。"

#: ../../rst/dev_guide/testing_integration.rst:20
msgid "Every new module and plugin should have integration tests, even if the tests cannot be run on Ansible CI infrastructure. In this case, the tests should be marked with the ``unsupported`` alias in `aliases file <https://docs.ansible.com/ansible/latest/dev_guide/testing/sanity/integration-aliases.html>`_."
msgstr "テストを Ansible CI インフラストラクチャーで実行できない場合でも、新しいモジュールとプラグインには統合テストが必要です。この場合、テストは `aliases ファイル <https://docs.ansible.com/ansible/latest/dev_guide/testing/sanity/integration-aliases.html>`_ の ``unsupported`` エイリアスでマーク付けする必要があります。"

#: ../../rst/dev_guide/testing_integration.rst:24
msgid "Quick Start"
msgstr "クイックスタート"

#: ../../rst/dev_guide/testing_integration.rst:26
msgid "It is highly recommended that you install and activate the ``argcomplete`` python package. It provides tab completion in ``bash`` for the ``ansible-test`` test runner."
msgstr "python パッケージ ``argcomplete`` をインストールし、アクティベートすることが強く推奨されます。これにより、テストランナー ``ansible-test`` に ``bash`` のタブ補完が提供されます。"

#: ../../rst/dev_guide/testing_integration.rst:30
msgid "Configuration"
msgstr "設定"

#: ../../rst/dev_guide/testing_integration.rst:33
msgid "ansible-test command"
msgstr "ansible-test コマンド"

#: ../../rst/dev_guide/testing_integration.rst:35
msgid "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:"
msgstr "以下の例では、``bin/`` が ``$PATH`` であることを前提としています。これは、``env-setup`` コマンドで環境を初期化する簡単な方法になります。"

#: ../../rst/dev_guide/testing_integration.rst:43
msgid "You can also call ``ansible-test`` with the full path:"
msgstr "完全パスで ``ansible-test`` を呼び出すこともできます。"

#: ../../rst/dev_guide/testing_integration.rst:50
msgid "integration_config.yml"
msgstr "integration_config.yml"

#: ../../rst/dev_guide/testing_integration.rst:52
msgid "Making your own version of ``integration_config.yml`` can allow for setting some tunable parameters to help run the tests better in your environment.  Some tests (for example, cloud tests) will only run when access credentials are provided.  For more information about supported credentials, refer to the various ``cloud-config-*.template`` files in the ``test/integration/`` directory."
msgstr "自身で作成した ``integration_config.yml`` があると、一部の調整可能なパラメーターを設定して、環境により適切にテストを実行できます。一部のテスト (クラウドテストなど) は、アクセス認証情報が提供されている場合にのみ実行されます。サポート対象の認証情報の詳細は、``test/integration/`` ディレクトリーでさまざまな ``cloud-config-*.template`` ファイルを参照してください。"

#: ../../rst/dev_guide/testing_integration.rst:61
msgid "Some tests assume things like hg, svn, and git are installed, and in path.  Some tests (such as those for Amazon Web Services) need separate definitions, which will be covered later in this document."
msgstr "一部のテストでは、hg、svn、git などがインストールされ、パスにあることを前提としています。一部のテスト (Amazon Web Services のテストなど) には個別の定義が必要です。これについては、このドキュメントの後半で説明します。"

#: ../../rst/dev_guide/testing_integration.rst:65
msgid "(Complete list pending)"
msgstr "(完全はリストは後日追加されます)"

#: ../../rst/dev_guide/testing_integration.rst:68
msgid "Non-destructive Tests"
msgstr "非破壊テスト"

#: ../../rst/dev_guide/testing_integration.rst:70
msgid "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."
msgstr "これらのテストはサブディレクトリー内のファイルを修正しますが、パッケージやテストのサブディレクトリー以外にあるものをインストールしたり削除したりするようなことはしません。また、システムサービスの再設定やバウンスも行いません。"

#: ../../rst/dev_guide/testing_integration.rst:73
msgid "Running integration tests within containers"
msgstr "コンテナー内での統合テストの実行"

#: ../../rst/dev_guide/testing_integration.rst:75
msgid "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 ubuntu2004``. 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)."
msgstr "統合テストによる潜在的な変更からシステムを守り、適切な依存関係セットが利用可能になるようにするには、常に ``--docker`` オプションをつけて統合テストを実行することが推奨されます (``--docker ubuntu2004`` など)。オプションについては、`list of supported container images <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_data/completion/docker.txt>`_を参照してください (``default`` イメージは、健全性テストとユニットテスト、およびクラウドモジュールなどのプラットフォームに依存しない統合テストに使用されます)。"

#: ../../rst/dev_guide/testing_integration.rst:77
msgid "Run as follows for all POSIX platform tests executed by our CI system in a Fedora 34 container:"
msgstr "Fedora 34 コンテナーで CI システムによって実行されるすべての POSIX プラットフォームテストに対して次のように実行します。"

#: ../../rst/dev_guide/testing_integration.rst:83
msgid "You can target a specific tests as well, such as for individual modules:"
msgstr "個々のモジュールなど、特定のテストを対象とすることもできます。"

#: ../../rst/dev_guide/testing_integration.rst:89
msgid "You can use the ``-v`` option to make the output more verbose:"
msgstr "``-v`` オプションを使用すると、出力をさらに詳細にすることができます。"

#: ../../rst/dev_guide/testing_integration.rst:95
msgid "Use the following command to list all the available targets:"
msgstr "利用可能なターゲットの一覧を表示するには、以下のコマンドを実行します。"

#: ../../rst/dev_guide/testing_integration.rst:101
msgid "Bash users"
msgstr "Bash ユーザー"

#: ../../rst/dev_guide/testing_integration.rst:103
msgid "If you use ``bash`` with ``argcomplete``, obtain a full list by doing: ``ansible-test integration <tab><tab>``"
msgstr "``bash`` を ``argcomplete`` とともに使用する場合は、``ansible-test integration <tab><tab>`` を実行して完全な一覧を取得します。"

#: ../../rst/dev_guide/testing_integration.rst:106
msgid "Destructive Tests"
msgstr "破壊テスト"

#: ../../rst/dev_guide/testing_integration.rst:108
msgid "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:"
msgstr "これらのテストでは、いくつかの簡単なパッケージをインストールおよび削除できます。これらを Docker などの仮想環境専用にすることが推奨されます。これらは、ファイルシステムを再フォーマットしません。"

#: ../../rst/dev_guide/testing_integration.rst:116
msgid "Windows Tests"
msgstr "Windows テスト"

#: ../../rst/dev_guide/testing_integration.rst:118
msgid "These tests exercise the ``winrm`` connection plugin and Windows modules.  You'll need to define an inventory with a remote Windows Server to use for testing, and enable PowerShell Remoting to continue."
msgstr "これらのテストは、``winrm`` connection プラグインと Windows モジュールに従います。テストに使用するリモート Windows Server を持つインベントリーを定義し、PowerShell Remoting を継続できるようにする必要があります。"

#: ../../rst/dev_guide/testing_integration.rst:122
msgid "Running these tests may result in changes to your Windows host, so don't run them against a production/critical Windows environment."
msgstr "これらのテストを実行すると、Windows ホストが変更になる可能性があるため、実稼働環境や重要な Windows 環境では実行しないでください。"

#: ../../rst/dev_guide/testing_integration.rst:125
msgid "Enable PowerShell Remoting (run on the Windows host via Remote Desktop):"
msgstr "PowerShell Remoting を有効にします (リモートデスクトップを介して Windows ホストで実行します)。"

#: ../../rst/dev_guide/testing_integration.rst:131
msgid "Define Windows inventory:"
msgstr "Windows インベントリーを定義します。"

#: ../../rst/dev_guide/testing_integration.rst:138
msgid "Run the Windows tests executed by our CI system:"
msgstr "CI システムで実行する Windows テストを実行します。"

#: ../../rst/dev_guide/testing_integration.rst:145
msgid "Tests in containers"
msgstr "コンテナーでのテスト"

#: ../../rst/dev_guide/testing_integration.rst:147
msgid "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."
msgstr "DockerまたはPodman がインストールされた Linux システムをお持ちの場合は、Ansible の継続的統合 (CI) システムで使用されているものと同じコンテナーを使用して統合テストを実行することが推奨されます。"

#: ../../rst/dev_guide/testing_integration.rst:150
msgid "Podman"
msgstr "Podman"

#: ../../rst/dev_guide/testing_integration.rst:152
msgid "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``."
msgstr "デフォルトで、Podman は Docker CLI がインストールされていない場合にのみ使用されます。Docker がインストールされていて Podman を使用する必要がある場合は、環境変数 ``ANSIBLE_TEST_PREFER_PODMAN`` を設定してこの動作を変更できます。"

#: ../../rst/dev_guide/testing_integration.rst:155
msgid "Docker on non-Linux"
msgstr "Linux 以外の Docker"

#: ../../rst/dev_guide/testing_integration.rst:157
msgid "Using Docker Engine to run Docker on a non-Linux host (such as macOS) is not recommended. Some tests may fail, depending on the image used for testing. Using the ``--docker-privileged`` option when running ``integration`` (not ``network-integration`` or ``windows-integration``) may resolve the issue."
msgstr "Docker Engine を使用して (macOS などの) Linux 以外のホストで Docker を実行することは推奨されません。テストに使用されるイメージによっては、一部のテストが失敗する可能性があります。(``network-integration`` または ``windows-integration``ではなく) ``integration`` の実行時に ``--docker-privileged`` オプションを使用すると問題が解決する可能性があります。"

#: ../../rst/dev_guide/testing_integration.rst:162
msgid "Running Integration Tests"
msgstr "統合テストの実行"

#: ../../rst/dev_guide/testing_integration.rst:164
msgid "To run all CI integration test targets for POSIX platforms in a Ubuntu 18.04 container:"
msgstr "Ubuntu 18.04 コンテナー内の POSIX プラットフォームに CI 統合テストターゲットすべてを実行するには、次のコマンドを実行します。"

#: ../../rst/dev_guide/testing_integration.rst:170
msgid "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:"
msgstr "特定のテストを実行することも、別の Linux ディストリビューションを選択することもできます。たとえば、Ubuntu 18.04 コンテナーで ``ping`` モジュールのテストを実行するには、次を実行します。"

#: ../../rst/dev_guide/testing_integration.rst:180
msgid "Container Images"
msgstr "コンテナーイメージ"

#: ../../rst/dev_guide/testing_integration.rst:182
msgid "Container images are updated regularly. To see the current list of container images:"
msgstr "コンテナーイメージは定期的に更新されます。現在のコンテナーイメージ一覧を表示するには、以下を実行します。"

#: ../../rst/dev_guide/testing_integration.rst:188
msgid "The list is under the **target docker images and supported python version** heading."
msgstr "この一覧は、**target docker images and supported python version** の見出しの下にあります。"

#: ../../rst/dev_guide/testing_integration.rst:191
msgid "Legacy Cloud Tests"
msgstr "レガシーのクラウドテスト"

#: ../../rst/dev_guide/testing_integration.rst:193
msgid "Some of the cloud tests run as normal integration tests, and others run as legacy tests; see the :ref:`testing_integration_legacy` page for more information."
msgstr "一部のクラウドテストは通常の統合テストとして実行し、その他はレガシーテストとして実行します。詳細は、「:ref:`testing_integration_legacy`」のドキュメントを参照してください。"

#: ../../rst/dev_guide/testing_integration.rst:198
msgid "Other configuration for Cloud Tests"
msgstr "クラウドテストのその他の設定"

#: ../../rst/dev_guide/testing_integration.rst:200
msgid "In order to run some tests, you must provide access credentials in a file named ``cloud-config-aws.yml`` or ``cloud-config-cs.ini`` in the test/integration directory. Corresponding .template files are available for for syntax help.  The newer AWS tests now use the file test/integration/cloud-config-aws.yml"
msgstr "test/integration ディレクトリーにある ``cloud-config-aws.yml`` または ``cloud-config-cs.ini`` という名前のファイルにあるアクセス認証情報を指定する必要があります。構文ヘルプでは、対応する .template ファイルを利用できます。新しい AWS テストでは、test/integration/cloud-config-aws.yml ファイルが使用されるようになりました。"

#: ../../rst/dev_guide/testing_integration.rst:206
#: ../../rst/dev_guide/testing_integration_legacy.rst:60
msgid "IAM policies for AWS"
msgstr "AWS の IAM ポリシー"

#: ../../rst/dev_guide/testing_integration.rst:208
msgid "Ansible needs fairly wide ranging powers to run the tests in an AWS account.  This rights can be provided to a dedicated user. These need to be configured before running the test."
msgstr "Ansible は、AWS アカウントでテストを実行するために非常に幅広い権限が必要になります。この権限は専用のユーザーに提供できます。これらの権限は、テストを実行する前に設定する必要があります。"

#: ../../rst/dev_guide/testing_integration.rst:211
msgid "testing-policies"
msgstr "testing-policies"

#: ../../rst/dev_guide/testing_integration.rst:213
msgid "The GitHub repository `mattclay/aws-terminator <https://github.com/mattclay/aws-terminator/>`_ contains two sets of policies used for all existing AWS module integratoin tests. The `hacking/aws_config/setup_iam.yml` playbook can be used to setup two groups:"
msgstr "GitHub リポジトリー `mattclay/aws-terminator <https://github.com/mattclay/aws-terminator/>`_ には、既存の AWS モジュールの統合テストに使用するポリシーのセットが 2 つ含まれます。Playbook `hacking/aws_config/setup_iam.yml` を使用すると、2 つのグループを設定できます。"

#: ../../rst/dev_guide/testing_integration.rst:217
msgid "`ansible-integration-ci` will have the policies applied necessary to run any integration tests not marked as `unsupported` and are designed to mirror those used by Ansible's CI."
msgstr "`ansible-integration-ci` は、統合テストの実行に必要となるポリシーを適用すると共に、`unsupported` と識別されず、Ansible の CI で使用されるミラーリング用に設計されています。"

#: ../../rst/dev_guide/testing_integration.rst:220
msgid "`ansible-integration-unsupported` will have the additional policies applied necessary to run the integration tests marked as `unsupported` including tests for managing IAM roles, users and groups."
msgstr "`ansible-integration-unsupported` は、IAM ロール、ユーザー、およびグループを管理するためのテストを含む `unsupported` とマークされた統合テストの実行に必要な追加のポリシーが適用されます。"

#: ../../rst/dev_guide/testing_integration.rst:224
msgid "Once the groups have been created, you'll need to create a user and make the user a member of these groups. The policies are designed to minimize the rights of that user.  Please note that while this policy does limit the user to one region, this does not fully restrict the user (primarily due to the limitations of the Amazon ARN notation). The user will still have wide privileges for viewing account definitions, and will also able to manage some resources that are not related to testing (for example, AWS lambdas with different names).  Tests should not be run in a primary production account in any case."
msgstr "グループが作成されたら、ユーザーを作成して、そのユーザーをこれらのグループのメンバーにする必要があります。ポリシーは、そのユーザーの権利を最小限にするためのものです。このポリシーでは、ユーザーを 1 つの地域に限定していますが、これはユーザーを完全には制限していないことに注意してください (主に Amazon ARN 表記の制限によるものです)。このユーザーは、アカウント定義を閲覧するための広い権限を持っており、テストに関係のないいくつかのリソース (たとえば、異なる名前の AWS ラムダ) を管理することもできます。どのような場合でも、テストを実稼働環境用のプライマリーアカウントで実行すべきではありません。"

#: ../../rst/dev_guide/testing_integration.rst:232
#: ../../rst/dev_guide/testing_integration_legacy.rst:78
msgid "Other Definitions required"
msgstr "その他に必要な定義"

#: ../../rst/dev_guide/testing_integration.rst:234
#: ../../rst/dev_guide/testing_integration_legacy.rst:80
msgid "Apart from installing the policy and giving it to the user identity running the tests, a lambda role `ansible_integration_tests` has to be created which has lambda basic execution privileges."
msgstr "ポリシーをインストールして、テストを実行しているユーザ ID にそれを付与することとは別に、ラムダロール `ansible_integration_tests` を作成する必要があります。これは、ラムダの基本的な実行権限を持ちます。"

#: ../../rst/dev_guide/testing_integration.rst:240
msgid "Network Tests"
msgstr "ネットワークテスト"

#: ../../rst/dev_guide/testing_integration.rst:242
msgid "For guidance on writing network test see :ref:`testing_resource_modules`."
msgstr "ネットワークテストの書き込みに関する情報は、「:ref:`testing_resource_modules`」を参照してください。"

#: ../../rst/dev_guide/testing_integration.rst:246
msgid "Where to find out more"
msgstr "その他の詳細情報"

#: ../../rst/dev_guide/testing_integration.rst:248
msgid "If you'd like to know more about the plans for improving testing Ansible, join the `Testing Working Group <https://github.com/ansible/community/blob/main/meetings/README.md>`_."
msgstr "Ansible テストを改善する詳細な計画を確認したい場合は、`Testing Working Group <https://github.com/ansible/community/blob/main/meetings/README.md>`_ にご参加ください。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:7
msgid "Testing using the Legacy Integration system"
msgstr "レガシー統合システムを使用したテスト"

#: ../../rst/dev_guide/testing_integration_legacy.rst:11
msgid "This page details how to run the integration tests that haven't been ported to the new ``ansible-test`` framework."
msgstr "このページでは、新しい ``ansible-test`` フレームワークに移植されていない統合テストの実行方法を説明します。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:13
msgid "The following areas are still tested using the legacy ``make tests`` command:"
msgstr "以下のエリアは、レガシーの ``make tests`` コマンドを使用してテストされます。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:15
msgid "amazon (some)"
msgstr "amazon (一部)"

#: ../../rst/dev_guide/testing_integration_legacy.rst:16
msgid "azure"
msgstr "azure"

#: ../../rst/dev_guide/testing_integration_legacy.rst:17
msgid "cloudflare"
msgstr "cloudflare"

#: ../../rst/dev_guide/testing_integration_legacy.rst:18
msgid "cloudscale"
msgstr "cloudscale"

#: ../../rst/dev_guide/testing_integration_legacy.rst:19
msgid "cloudstack"
msgstr "cloudstack"

#: ../../rst/dev_guide/testing_integration_legacy.rst:20
msgid "consul"
msgstr "consul"

#: ../../rst/dev_guide/testing_integration_legacy.rst:21
msgid "exoscale"
msgstr "exoscale"

#: ../../rst/dev_guide/testing_integration_legacy.rst:22
msgid "gce"
msgstr "gce"

#: ../../rst/dev_guide/testing_integration_legacy.rst:23
msgid "jenkins"
msgstr "jenkins"

#: ../../rst/dev_guide/testing_integration_legacy.rst:24
msgid "rackspace"
msgstr "rackspace"

#: ../../rst/dev_guide/testing_integration_legacy.rst:26
msgid "Over time the above list will be reduced as tests are ported to the ``ansible-test`` framework."
msgstr "テストが ``ansible-test`` フレームワークに移植されると、上記のリストは徐々に少なくなっていきます。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:30
msgid "Running Cloud Tests"
msgstr "クラウドテストの実行"

#: ../../rst/dev_guide/testing_integration_legacy.rst:32
msgid "Cloud tests exercise capabilities of cloud modules (for example, ec2_key).  These are not 'tests run in the cloud' so much as tests that use the cloud modules and are organized by cloud provider."
msgstr "クラウドテストは、クラウドモジュール (ec2_key など) の機能を実行します。これらは、「クラウドで実行されるテスト」ではなく、クラウドモジュールを使用し、クラウドプロバイダーによって編成されたテストです。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:36
msgid "Some AWS tests may use environment variables. It is recommended to either unset any AWS environment variables( such as ``AWS_DEFAULT_PROFILE``, ``AWS_SECRET_ACCESS_KEY``, and so on) or be sure that the environment variables match the credentials provided in ``credentials.yml`` to ensure the tests run with consistency to their full capability on the expected account. See `AWS CLI docs <https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html>`_ for information on creating a profile."
msgstr "AWS テストによっては、環境変数を使用するものもあります。AWS 環境変数 (``AWS_DEFAULT_PROFILE``、``AWS_SECRET_ACCESS_KEY`` など) の設定を解除するか、環境変数が ``credentials.yml`` で提供される認証情報と一致することを確認して、予想されるアカウントの完全な機能に一貫性のあるテストが実行されるようにすることが推奨されます。プロファイルの作成に関する情報は、`AWS CLI ドキュメント <https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html>`_ を参照してください。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:38
msgid "Subsets of tests may be run by ``#commenting`` out unnecessary roles in the appropriate playbook, such as ``test/integration/amazon.yml``."
msgstr "テストのサブセットは、適切な Playbook の 不要なロールを ``#commenting`` でコメントアウトすることで実行できます (例: ``test/integration/amazon.yml``)。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:40
msgid "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."
msgstr "クラウドテストを実行するには、``credentials.yml`` という名前のファイルでアクセス認証情報を指定する必要があります。構文ヘルプには、``credentials.template`` と名前の付いたサンプル認証情報ファイルを利用できます。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:44
msgid "Provide cloud credentials:"
msgstr "クラウド認証を提供します。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:53
msgid "Other configuration"
msgstr "その他の設定"

#: ../../rst/dev_guide/testing_integration_legacy.rst:55
msgid "In order to run some tests, you must provide access credentials in a file named ``credentials.yml``. A sample credentials file named ``credentials.template`` is available for syntax help."
msgstr "いくつかのテストを実行するには、``credentials.yml`` という名前のファイルでアクセス認証情報を指定する必要があります。構文ヘルプには、``credentials.template`` と名前の付いたサンプル認証情報ファイルを利用できます。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:62
msgid "In order to run the tests in an AWS account ansible needs fairly wide ranging powers which can be provided to a dedicated user or temporary credentials using a specific policy configured in the AWS account."
msgstr "AWS アカウントでテストを実行するには、Ansible に、AWS アカウントで設定された特定のポリシーを使用して、専用のユーザや一時的な認証情報に提供できる、かなり広範囲の権限が必要となります。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:67
msgid "testing-iam-policy.json.j2"
msgstr "testing-iam-policy.json.j2"

#: ../../rst/dev_guide/testing_integration_legacy.rst:69
msgid "The testing-iam-policy.json.j2 file contains a policy which can be given to the user running the tests to give close to minimum rights required to run the tests.  Please note that this does not fully restrict the user; The user has wide privileges for viewing account definitions and is also able to manage some resources that are not related to testing (for example, AWS lambdas with different names) primarily due to the limitations of the Amazon ARN notation.  At the very least the policy limits the user to one region, however tests should not be run in a primary production account in any case."
msgstr "testing-iam-policy.json.j2 ファイルには、テストを実行するユーザーに付与するポリシーが含まれており、テストの実行に必要な最低限の権限に近いものを付与することができます。なお、これは完全な制限ではないため注意してください。このユーザーは、アカウント定義を閲覧する幅広い権限を持ち、主に Amazon ARN 表記の制限により、テストに関係のない一部のリソース (たとえば、異なる名前の AWS ラムダ) を管理することもできます。少なくとも、このポリシーではユーザーを 1 つのリージョンに限定していますが、いかなる場合でも、テストは実稼働環境のプライマリーアカウントで実行すべきではありません。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:86
#: ../../rst/dev_guide/testing_units.rst:24
msgid "Running Tests"
msgstr "テストの実行"

#: ../../rst/dev_guide/testing_integration_legacy.rst:88
msgid "The tests are invoked via a ``Makefile``."
msgstr "テストは ``Makefile`` 経由で呼び出されます。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:90
msgid "If you haven't already got Ansible available use the local checkout by doing:"
msgstr "Ansible がまだ利用可能でない場合は、以下の方法でローカルチェックアウトを使用します。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:96
msgid "Run the tests by doing:"
msgstr "以下を実行してテストを実行します。"

#: ../../rst/dev_guide/testing_integration_legacy.rst:108
msgid "Possible cost of running cloud tests"
msgstr "クラウドテストにかかる可能性のあるコスト"

#: ../../rst/dev_guide/testing_integration_legacy.rst:110
msgid "Running cloud integration tests will create and destroy cloud resources. Running these tests may result in additional fees associated with your cloud account. Care is taken to ensure that created resources are removed. However, it is advisable to inspect your AWS console to ensure no unexpected resources are running."
msgstr "クラウド統合テストを実行すると、クラウドリソースが作成および破棄されます。このようなテストを実行すると、クラウドアカウントに関連する追加料金が発生する可能性があります。作成されたリソースが確実に削除されるように注意が払われます。ただし、AWS コンソールを調べて、予期しないリソースが実行していないことを確認することが推奨されます。"

#: ../../rst/dev_guide/testing_pep8.rst:7
msgid "PEP 8"
msgstr "PEP 8"

#: ../../rst/dev_guide/testing_pep8.rst:11
msgid "`PEP 8`_ style guidelines are enforced by `pycodestyle`_ on all python files in the repository by default."
msgstr "`PEP 8`_ スタイルのガイドラインは、デフォルトでリポジトリーにあるすべての python ファイルで `pycodestyle`_ によって強制されます。"

#: ../../rst/dev_guide/testing_pep8.rst:14
msgid "Running Locally"
msgstr "ローカルでの実行"

#: ../../rst/dev_guide/testing_pep8.rst:16
msgid "The `PEP 8`_ check can be run locally with::"
msgstr "`PEP 8`_ チェックは、以下を使用してローカルで実行できます。"

#: ../../rst/dev_guide/testing_running_locally.rst:9
msgid "This document describes how to:"
msgstr "本書では、以下を行う方法を説明します。"

#: ../../rst/dev_guide/testing_running_locally.rst:11
msgid "Run tests locally using ``ansible-test``"
msgstr "``ansible-test`` を使用してテストをローカルで実行します。"

#: ../../rst/dev_guide/testing_running_locally.rst:12
msgid "Extend"
msgstr "拡張"

#: ../../rst/dev_guide/testing_running_locally.rst:20
msgid "There are no special requirements for running ``ansible-test`` on Python 2.7 or later. The ``argparse`` package is required for Python 2.6. The requirements for each ``ansible-test`` command are covered later."
msgstr "Python 2.7 以降には、``ansible-test`` を実行するための特別な要件がありません。Python 2.6 には ``argparse`` パッケージが必要です。各 ``ansible-test`` コマンドの要件は、後で説明します。"

#: ../../rst/dev_guide/testing_running_locally.rst:26
msgid "Test Environments"
msgstr "テスト環境"

#: ../../rst/dev_guide/testing_running_locally.rst:28
msgid "Most ``ansible-test`` commands support running in one or more isolated test environments to simplify testing."
msgstr "ほとんどの ``ansible-test`` コマンドは、テストを簡単にするために、1 つ以上の分離テスト環境での実行をサポートします。"

#: ../../rst/dev_guide/testing_running_locally.rst:32
msgid "Remote"
msgstr "リモート"

#: ../../rst/dev_guide/testing_running_locally.rst:34
msgid "The ``--remote`` option runs tests in a cloud hosted environment. An API key is required to use this feature."
msgstr "``--remote`` オプションは、クラウドホスト環境でテストを実行します。この機能を使用するには API キーが必要です。"

#: ../../rst/dev_guide/testing_running_locally.rst:37
msgid "Recommended for integration tests."
msgstr "統合テストへ推奨事項"

#: ../../rst/dev_guide/testing_running_locally.rst:39
msgid "See the `list of supported platforms and versions <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_data/completion/remote.txt>`_ for additional details."
msgstr "詳細は、「`サポート対象のプラットフォームおよびバージョンの一覧 <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_data/completion/remote.txt>`_」を参照してください。"

#: ../../rst/dev_guide/testing_running_locally.rst:42
msgid "Environment Variables"
msgstr "環境変数"

#: ../../rst/dev_guide/testing_running_locally.rst:44
msgid "When using environment variables to manipulate tests there some limitations to keep in mind. Environment variables are:"
msgstr "環境変数を使用してテストを操作する際には、以下の制限事項に留意してください。環境変数は以下のようになります。"

#: ../../rst/dev_guide/testing_running_locally.rst:46
msgid "Not propagated from the host to the test environment when using the ``--docker`` or ``--remote`` options."
msgstr "``--docker`` オプションまたは ``--remote`` オプションを使用する場合は、ホストからテスト環境に伝播されません。"

#: ../../rst/dev_guide/testing_running_locally.rst:47
msgid "Not exposed to the test environment unless enabled in ``test/lib/ansible_test/_internal/util.py`` in the ``common_environment`` function."
msgstr "``common_environment`` 関数の ``test/lib/ansible_test/_internal/util.py`` で有効にされていない限り、テスト環境には公開されません。"

#: ../../rst/dev_guide/testing_running_locally.rst:49
msgid "Example: ``ANSIBLE_KEEP_REMOTE_FILES=1`` can be set when running ``ansible-test integration --venv``. However, using the ``--docker`` option would require running ``ansible-test shell`` to gain access to the Docker environment. Once at the shell prompt, the environment variable could be set and the tests executed. This is useful for debugging tests inside a container by following the :ref:`Debugging AnsibleModule-based modules <debugging_modules>` instructions."
msgstr "例: ``ansible-test integration --venv`` の実行時に ``ANSIBLE_KEEP_REMOTE_FILES=1`` を設定できますが、``--docker`` オプションを使用すると、``ansible-test shell`` を実行し、Docker 環境へのアクセスが必要になります。シェルプロンプトでは、環境変数を設定してテストを行う可能性があります。これは、:ref:`Debugging AnsibleModule-based modules <debugging_modules>` の指示に従って、コンテナー内でテストをデバッグする上で役立ちます。"

#: ../../rst/dev_guide/testing_running_locally.rst:55
msgid "Interactive Shell"
msgstr "インタラクティブシェル"

#: ../../rst/dev_guide/testing_running_locally.rst:57
msgid "Use the ``ansible-test shell`` command to get an interactive shell in the same environment used to run tests. Examples:"
msgstr "``ansible-test shell`` コマンドを使用して、テストを実行するのに使用する同じ環境でインタラクティブシェルを取得します。以下は例になります。"

#: ../../rst/dev_guide/testing_running_locally.rst:59
msgid "``ansible-test shell --docker`` - Open a shell in the default docker container."
msgstr "``ansible-test shell --docker`` - デフォルトの docker コンテナーでシェルを開きます。"

#: ../../rst/dev_guide/testing_running_locally.rst:60
msgid "``ansible-test shell --venv --python 3.6`` - Open a shell in a Python 3.6 virtual environment."
msgstr "``ansible-test shell --venv --python 3.6`` - Python 3.6 仮想環境でシェルを開きます。"

#: ../../rst/dev_guide/testing_running_locally.rst:64
msgid "Code Coverage"
msgstr "コードの対象範囲"

#: ../../rst/dev_guide/testing_running_locally.rst:66
msgid "Code coverage reports make it easy to identify untested code for which more tests should be written.  Online reports are available but only cover the ``devel`` branch (see :ref:`developing_testing`).  For new code local reports are needed."
msgstr "コードの対象範囲レポートは、より多くのテストが記述されるべき未テストのコードを簡単に識別することができます。オンラインレポートが利用できますが、``devel`` ブランチのみを扱います (:ref:`developing_testing` を参照)。新規コードのローカルレポートが必要な場合は、以下を行います。"

#: ../../rst/dev_guide/testing_running_locally.rst:70
msgid "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:"
msgstr "コードカバレッジデータを収集するテストコマンドに ``--coverage`` オプションを追加します。分離した python 環境を作成する ``--venv`` オプションまたは ``--docker`` オプションを使用していない場合は、``--requirements`` オプションを使用してカバレッジモジュールの正しいバージョンがインストールされていることを確認する必要があります。"

#: ../../rst/dev_guide/testing_running_locally.rst:83
#: ../../rst/dev_guide/testing_units.rst:197
msgid "Reports can be generated in several different formats:"
msgstr "Report は、複数の形式で生成できます。"

#: ../../rst/dev_guide/testing_running_locally.rst:85
#: ../../rst/dev_guide/testing_units.rst:199
msgid "``ansible-test coverage report`` - Console report."
msgstr "``ansible-test coverage report`` - コンソールレポート。"

#: ../../rst/dev_guide/testing_running_locally.rst:86
#: ../../rst/dev_guide/testing_units.rst:200
msgid "``ansible-test coverage html`` - HTML report."
msgstr "``ansible-test coverage html`` - HTML レポート。"

#: ../../rst/dev_guide/testing_running_locally.rst:87
#: ../../rst/dev_guide/testing_units.rst:201
msgid "``ansible-test coverage xml`` - XML report."
msgstr "``ansible-test coverage xml`` - XML レポート。"

#: ../../rst/dev_guide/testing_running_locally.rst:89
msgid "To clear data between test runs, use the ``ansible-test coverage erase`` command. For a full list of features see the online help:"
msgstr "テスト実行間のデータを消去するには、``ansible-test coverage erase`` コマンドを使用します。機能の全一覧については、オンラインヘルプを参照してください。"

#: ../../rst/dev_guide/testing_sanity.rst:11
msgid "Sanity tests are made up of scripts and tools used to perform static code analysis. The primary purpose of these tests is to enforce Ansible coding standards and requirements."
msgstr "健全性テストは、静的コード分析の実行に使用されるスクリプトおよびツールで構成されています。これらのテストの主な目的は、Ansible コーディングの仕様および要件を適用することです。"

#: ../../rst/dev_guide/testing_sanity.rst:14
msgid "Tests are run with ``ansible-test sanity``. All available tests are run unless the ``--test`` option is used."
msgstr "テストは、``ansible-test sanity`` で実行します。``--test`` オプションを使用しない限り、利用可能なテストはすべて実行します。"

#: ../../rst/dev_guide/testing_sanity.rst:19
msgid "How to run"
msgstr "実行方法"

#: ../../rst/dev_guide/testing_sanity.rst:22
msgid "To run sanity tests using docker, always use the default docker image by passing the ``--docker`` or ``--docker default`` argument."
msgstr "docker を使用して健常性テストを実行するには、常に ``--docker`` 引数または ``--docker default`` 引数を渡すことでデフォルトの docker イメージを常に使用します。"

#: ../../rst/dev_guide/testing_sanity.rst:26
msgid "When using docker and the ``--base-branch`` argument, also use the ``--keep-git`` argument to avoid git related errors."
msgstr "docker および ``--base-branch`` 引数を使用する場合は、git 関連のエラーを回避するために ``--keep-git`` 引数も使用します。"

#: ../../rst/dev_guide/testing_sanity.rst:52
#: ../../rst/dev_guide/testing_units.rst:17
msgid "Available Tests"
msgstr "利用可能なテスト"

#: ../../rst/dev_guide/testing_sanity.rst:54
msgid "Tests can be listed with ``ansible-test sanity --list-tests``."
msgstr "テストは ``ansible-test sanity --list-tests`` で一覧表示できます。"

#: ../../rst/dev_guide/testing_units.rst:7
msgid "Unit Tests"
msgstr "ユニットテスト"

#: ../../rst/dev_guide/testing_units.rst:9
msgid "Unit tests are small isolated tests that target a specific library or module.  Unit tests in Ansible are currently the only way of driving tests from python within Ansible's continuous integration process. This means that in some circumstances the tests may be a bit wider than just units."
msgstr "ユニットテストは、特定のライブラリーまたはモジュールを対象とする小規模の分離テストです。現在、Ansible のユニットテストは、Ansible の継続的統合プロセスの中で、python からテストを実行する唯一の方法です。つまり、状況によっては、テストにはユニット以外のものも含まれる場合があることを意味します。"

#: ../../rst/dev_guide/testing_units.rst:19
msgid "Unit tests can be found in `test/units <https://github.com/ansible/ansible/tree/devel/test/units>`_. Notice that the directory structure of the tests matches that of ``lib/ansible/``."
msgstr "ユニットテストは `test/units <https://github.com/ansible/ansible/tree/devel/test/units>`_ にあります。テストのディレクトリー構造が ``lib/ansible/`` と一致することに注意してください。"

#: ../../rst/dev_guide/testing_units.rst:27
msgid "To run unit tests using docker, always use the default docker image by passing the ``--docker`` or ``--docker default`` argument."
msgstr "docker を使用してユニットテストを実行するには、``--docker`` 引数または ``--docker default`` 引数を渡すことで常にデフォルトの docker イメージを使用します。"

#: ../../rst/dev_guide/testing_units.rst:30
msgid "The Ansible unit tests can be run across the whole code base by doing:"
msgstr "Ansible のユニットテストは、以下の操作を実行してコードベース全体で実行できます。"

#: ../../rst/dev_guide/testing_units.rst:50
msgid "If you are running unit tests against things other than modules, such as module utilities, specify the whole file path:"
msgstr "モジュールユーティリティーなどのモジュール以外のものに対してユニットテストを実行している場合は、ファイルパス全体を指定します。"

#: ../../rst/dev_guide/testing_units.rst:56
msgid "For advanced usage see the online help:"
msgstr "高度な使用方法は、オンラインヘルプを参照してください。"

#: ../../rst/dev_guide/testing_units.rst:62
msgid "You can also run tests in Ansible's continuous integration system by opening a pull request.  This will automatically determine which tests to run based on the changes made in your pull request."
msgstr "プル要求を開いて、Ansible の継続的統合システムでテストを実行することもできます。これにより、プル要求で実行された変更に基づいて、実行されるテストが自動的に決定されます。"

#: ../../rst/dev_guide/testing_units.rst:70
msgid "If you are running ``ansible-test`` with the ``--docker`` or ``--venv`` option you do not need to install dependencies manually."
msgstr "``--docker`` オプションまたは ``--venv`` オプションを指定して ``ansible-test`` を実行している場合は、依存関係を手動でインストールする必要はありません。"

#: ../../rst/dev_guide/testing_units.rst:72
msgid "Otherwise you can install dependencies using the ``--requirements`` option, which will install all the required dependencies needed for unit tests. For example:"
msgstr "それ以外の場合は、``--requirements`` オプションを使用して依存関係をインストールし、ユニットテストに必要な依存関係をすべてインストールします。以下に例を示します。"

#: ../../rst/dev_guide/testing_units.rst:80
msgid "The list of unit test requirements can be found at `test/units/requirements.txt <https://github.com/ansible/ansible/tree/devel/test/units/requirements.txt>`_."
msgstr "ユニットテストの要件一覧は、`test/units/requirements.txt <https://github.com/ansible/ansible/tree/devel/test/units/requirements.txt>`_ を参照してください。"

#: ../../rst/dev_guide/testing_units.rst:83
msgid "This does not include the list of unit test requirements for ``ansible-test`` itself, which can be found at `test/lib/ansible_test/_data/requirements/units.txt <https://github.com/ansible/ansible/tree/devel/test/lib/ansible_test/_data/requirements/units.txt>`_."
msgstr "これには、``ansible-test`` のユニットテスト要件のリストは含まれていません。それは、`test/lib/ansible_test/_data/requirements/units.txt <https://github.com/ansible/ansible/tree/devel/test/lib/ansible_test/_data/requirements/units.txt>`_ で見つけることができます。"

#: ../../rst/dev_guide/testing_units.rst:87
msgid "See also the `constraints <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_data/requirements/constraints.txt>`_ applicable to all test commands."
msgstr "すべてのコマンドに適用可能な「`制約 <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_data/requirements/constraints.txt>`_」も参照してください。"

#: ../../rst/dev_guide/testing_units.rst:93
msgid "Extending unit tests"
msgstr "ユニットテストの拡張"

#: ../../rst/dev_guide/testing_units.rst:96
msgid "What a unit test isn't"
msgstr "ユニットテスト以外のもの"

#: ../../rst/dev_guide/testing_units.rst:98
msgid "If you start writing a test that requires external services then you may be writing an integration test, rather than a unit test."
msgstr "外部サービスを必要とするテストを書き始めると、ユニットテストではなく統合テストを書くことができます。"

#: ../../rst/dev_guide/testing_units.rst:103
msgid "Structuring Unit Tests"
msgstr "ユニットテストの構造"

#: ../../rst/dev_guide/testing_units.rst:105
msgid "Ansible drives unit tests through `pytest <https://docs.pytest.org/en/latest/>`_. This means that tests can either be written a simple functions which are included in any file name like ``test_<something>.py`` or as classes."
msgstr "Ansible は、`pytest <https://docs.pytest.org/en/latest/>`_ でユニットテストを行います。これは、テストは、``test_<something>.py`` のファイル名またはクラスとして含まれる単純な関数を記述できることを意味します。"

#: ../../rst/dev_guide/testing_units.rst:109
msgid "Here is an example of a function:"
msgstr "以下は、関数の例です。"

#: ../../rst/dev_guide/testing_units.rst:121
msgid "Here is an example of a class:"
msgstr "以下はクラスの例です。"

#: ../../rst/dev_guide/testing_units.rst:143
msgid "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 few basic tests for a module.  The class-based test allows more tidy set up and tear down of pre-requisites, so if you have many test cases for your module you may want to refactor to use that."
msgstr "どちらの方法も、ほとんどの状況で正常に機能します。関数ベースのインターフェースの方がシンプルで速いため、モジュールにいくつかの基本的なテストを追加しようとしている場合は、ここから始めることが推奨されます。クラスベースのテストでは、前提条件の設定や分解をより整然と行うことができるため、モジュールに多くのテストケースがある場合は、それを使用するようにリファクタリングすることが推奨されます。"

#: ../../rst/dev_guide/testing_units.rst:149
msgid "Assertions using the simple ``assert`` function inside the tests will give full information on the cause of the failure with a trace-back of functions called during the assertion.  This means that plain asserts are recommended over other external assertion libraries."
msgstr "テスト内の簡単な ``assert`` 関数を使用するアサーションにより、アサーション中に呼び出される関数のトレースバックで障害に関する完全な情報が表示されます。これは、他の外部アサーションライブラリーよりも、プレーンアサートが推奨されることを意味します。"

#: ../../rst/dev_guide/testing_units.rst:154
msgid "A number of the unit test suites include functions that are shared between several modules, especially in the networking arena.  In these cases a file is created in the same directory, which is then included directly."
msgstr "多くのユニットテストスイートには、特にネットワークの分野では、複数のモジュールで共有される関数が含まれています。この場合は、同じディレクトリーにファイルが作成されます。このファイルは、直接含まれます。"

#: ../../rst/dev_guide/testing_units.rst:160
msgid "Module test case common code"
msgstr "モジュールテストケースの共通コード"

#: ../../rst/dev_guide/testing_units.rst:162
msgid "Keep common code as specific as possible within the `test/units/` directory structure. Don't import common unit test code from directories outside the current or parent directories."
msgstr "`test/units/` ディレクトリー構造内で可能な限り具体的に共通コードを維持します。現在のディレクトリーまたは親ディレクトリー以外のディレクトリーから共通のユニットテストコードをインポートしないでください。"

#: ../../rst/dev_guide/testing_units.rst:165
msgid "Don't import other unit tests from a unit test. Any common code should be in dedicated files that aren't themselves tests."
msgstr "ユニットテストから他のユニットテストをインポートしないでください。共通のコードは、テスト自体ではない専用のファイルに含める必要があります。"

#: ../../rst/dev_guide/testing_units.rst:170
msgid "Fixtures files"
msgstr "Fixtures ファイル"

#: ../../rst/dev_guide/testing_units.rst:172
msgid "To mock out fetching results from devices, or provide other complex data structures that come from external libraries, you can use ``fixtures`` to read in pre-generated data."
msgstr "デバイスからの結果の取得を模倣したり、外部ライブラリーから取得した他の複雑なデータ構造を提供するために、``fixtures`` を使用して事前に生成されたデータを読み込むことができます。"

#: ../../rst/dev_guide/testing_units.rst:175
msgid "You can check how `fixtures <https://github.com/ansible/ansible/tree/devel/test/units/module_utils/facts/fixtures/cpuinfo>`_ are used in `cpuinfo fact tests <https://github.com/ansible/ansible/blob/9f72ff80e3fe173baac83d74748ad87cb6e20e64/test/units/module_utils/facts/hardware/linux_data.py#L384>`_"
msgstr "`cpuinfo ファクトテスト <https://github.com/ansible/ansible/blob/9f72ff80e3fe173baac83d74748ad87cb6e20e64/test/units/module_utils/facts/hardware/linux_data.py#L384>`_ で、`fixtures <https://github.com/ansible/ansible/tree/devel/test/units/module_utils/facts/fixtures/cpuinfo>`_ が使用される方法を確認することができます。"

#: ../../rst/dev_guide/testing_units.rst:178
msgid "If you are simulating APIs you may find that Python placebo is useful.  See :ref:`testing_units_modules` for more information."
msgstr "API のシミュレーションをしているのであれば、Python のプラシーボが役に立つかもしれません。詳細は、「:ref:`testing_units_modules`」を参照してください。"

#: ../../rst/dev_guide/testing_units.rst:183
msgid "Code Coverage For New or Updated Unit Tests"
msgstr "新規ユニットテストまたは更新されたユニットテスト用のコード対応"

#: ../../rst/dev_guide/testing_units.rst:184
msgid "New code will be missing from the codecov.io coverage reports (see :ref:`developing_testing`), so local reporting is needed.  Most ``ansible-test`` commands allow you to collect code coverage; this is particularly useful when to indicate where to extend testing."
msgstr "codecov.io カバレッジレポートから新しいコードが欠落し (:ref:`developing_testing`を参照)、ローカルレポートが必要です。ほとんどの ``ansible-test`` コマンドを使用すると、コードカバレッジを収集できます。これは、テストを拡張する場所を示すときに特に役立ちます。"

#: ../../rst/dev_guide/testing_units.rst:188
msgid "To collect coverage data add the ``--coverage`` argument to your ``ansible-test`` command line:"
msgstr "カバレージデータを収集するには、``--coverage`` 引数を ``ansible-test`` コマンドラインに追加します。"

#: ../../rst/dev_guide/testing_units.rst:195
msgid "Results will be written to ``test/results/reports/coverage/index.html``"
msgstr "結果は ``test/results/reports/coverage/index.html`` に書き込まれます。"

#: ../../rst/dev_guide/testing_units.rst:203
msgid "To clear data between test runs, use the ``ansible-test coverage erase`` command.  See :ref:`testing_running_locally` for more information about generating coverage reports."
msgstr "テスト実行間のデータを消去するには、``ansible-test coverage erase`` コマンドを使用します。カバレッジレポートの生成の詳細は、「:ref:`testing_running_locally`」を参照してください。"

#: ../../rst/dev_guide/testing_units.rst:210
msgid ":ref:`testing_units_modules`"
msgstr ":ref:`testing_units_modules`"

#: ../../rst/dev_guide/testing_units.rst:211
msgid "Special considerations for unit testing modules"
msgstr "ユニットテストモジュールに関する特別な考慮事項"

#: ../../rst/dev_guide/testing_units.rst:212
#: ../../rst/dev_guide/testing_units_modules.rst:569
msgid ":ref:`testing_running_locally`"
msgstr ":ref:`testing_running_locally`"

#: ../../rst/dev_guide/testing_units.rst:213
#: ../../rst/dev_guide/testing_units_modules.rst:570
msgid "Running tests locally including gathering and reporting coverage data"
msgstr "カバレージデータの収集とレポートを含む、ローカルでのテストの実行"

#: ../../rst/dev_guide/testing_units.rst:214
#: ../../rst/dev_guide/testing_units_modules.rst:573
msgid "`Python 3 documentation - 26.4. unittest — Unit testing framework <https://docs.python.org/3/library/unittest.html>`_"
msgstr "`Python 3 documentation - 26.4. unittest — Unit testing framework <https://docs.python.org/3/library/unittest.html>`_"

#: ../../rst/dev_guide/testing_units.rst:215
#: ../../rst/dev_guide/testing_units_modules.rst:574
msgid "The documentation of the unittest framework in python 3"
msgstr "Python 3 におけるユニットテストフレームワークのドキュメント"

#: ../../rst/dev_guide/testing_units.rst:216
#: ../../rst/dev_guide/testing_units_modules.rst:575
msgid "`Python 2 documentation - 25.3. unittest — Unit testing framework <https://docs.python.org/3/library/unittest.html>`_"
msgstr "`Python 2 documentation - 25.3. unittest — Unit testing framework <https://docs.python.org/3/library/unittest.html>`_"

#: ../../rst/dev_guide/testing_units.rst:217
#: ../../rst/dev_guide/testing_units_modules.rst:576
msgid "The documentation of the earliest supported unittest framework - from Python 2.6"
msgstr "サポートされている初期のユニットテストフレームワークのドキュメント (Python 2.6)"

#: ../../rst/dev_guide/testing_units.rst:218
#: ../../rst/dev_guide/testing_units_modules.rst:577
msgid "`pytest: helps you write better programs <https://docs.pytest.org/en/latest/>`_"
msgstr "`pytest: helps you write better programs <https://docs.pytest.org/en/latest/>`_"

#: ../../rst/dev_guide/testing_units.rst:219
#: ../../rst/dev_guide/testing_units_modules.rst:578
msgid "The documentation of pytest - the framework actually used to run Ansible unit tests"
msgstr "pytest のドキュメント - Ansible ユニットテストの実行に実際に使用されているフレームワーク"

#: ../../rst/dev_guide/testing_units_modules.rst:7
msgid "Unit Testing Ansible Modules"
msgstr "Ansible モジュールのユニットテスト"

#: ../../rst/dev_guide/testing_units_modules.rst:16
msgid "This document explains why, how and when you should use unit tests for Ansible modules. The document doesn't apply to other parts of Ansible for which the recommendations are normally closer to the Python standard. There is basic documentation for Ansible unit tests in the developer guide :ref:`testing_units`. This document should be readable for a new Ansible module author. If you find it incomplete or confusing, please open a bug or ask for help on the #ansible-devel chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat <https://libera.chat/>`_)."
msgstr "このドキュメントでは、Ansible モジュールにユニットテストを使用する理由、方法、タイミングを説明します。このドキュメントは、通常 Python の標準に近い推奨事項を持つ Ansible の他の部分には適用されません。Ansible のユニットテストに関する基本的なドキュメントは、開発者ガイドの「:ref:`testing_units`」にあります。このドキュメントは、新しい Ansible モジュールの作成者にとって読みやすいものでなければなりません。不完全だったり、分かりにくかったりした場合は、バグを報告したり、#ansible-develチャットチャンネル で助けを求めたりしてください（ansible.imでMatrixを使用、または`irc.libera.chat <https://libera.chat/>`_でIRCを使用）。"

#: ../../rst/dev_guide/testing_units_modules.rst:24
msgid "What Are Unit Tests?"
msgstr "ユニットテストとは"

#: ../../rst/dev_guide/testing_units_modules.rst:26
msgid "Ansible includes a set of unit tests in the :file:`test/units` directory. These tests primarily cover the internals but can also cover Ansible modules. The structure of the unit tests matches the structure of the code base, so the tests that reside in the :file:`test/units/modules/` directory are organized by module groups."
msgstr "Ansible には、:file:`test/units` ディレクトリーにユニットテストのセットが含まれています。これらのテストは、主に内部に対応していますが、Ansible モジュールにも対応します。ユニットテストの構造はコードベースのベースの構造に一致し、:file:`test/units/modules/` ディレクトリーに含まれるテストはモジュールグループごとに編成されます。"

#: ../../rst/dev_guide/testing_units_modules.rst:31
msgid "Integration tests can be used for most modules, but there are situations where cases cannot be verified using integration tests. This means that Ansible unit test cases may extend beyond testing only minimal units and in some cases will include some level of functional testing."
msgstr "統合テストはほとんどのモジュールで使用できますが、統合テストではケースを検証できない場合もあります。つまり、Ansible ユニットテストケースは、最小限のユニットのみのテストにとどまらず、場合によっては、ある程度の機能テストが含まれることもあります。"

#: ../../rst/dev_guide/testing_units_modules.rst:38
msgid "Why Use Unit Tests?"
msgstr "ユニットテストを使用する理由"

#: ../../rst/dev_guide/testing_units_modules.rst:40
msgid "Ansible unit tests have advantages and disadvantages. It is important to understand these. Advantages include:"
msgstr "Ansible ユニットテストには長所と短所があり、その点を理解することは重要です。以下が挙げられます。"

#: ../../rst/dev_guide/testing_units_modules.rst:43
msgid "Most unit tests are much faster than most Ansible integration tests. The complete suite of unit tests can be run regularly by a developer on their local system."
msgstr "ほとんどのユニットテストは、ほとんどの Ansible 統合テストよりもはるかに高速です。ユニットテストの完全なスイートは、ローカルシステムで開発者が定期的に実行できます。"

#: ../../rst/dev_guide/testing_units_modules.rst:45
msgid "Unit tests can be run by developers who don't have access to the system which the module is designed to work on, allowing a level of verification that changes to core functions haven't broken module expectations."
msgstr "ユニットテストは、モジュールが動作するように設計されているシステムにアクセスできない開発者が実行することができ、コア機能への変更がモジュールの期待どおりであることをある程度検証できます。"

#: ../../rst/dev_guide/testing_units_modules.rst:48
msgid "Unit tests can easily substitute system functions allowing testing of software that would be impractical. For example, the ``sleep()`` function can be replaced and we check that a ten minute sleep was called without actually waiting ten minutes."
msgstr "ユニットテストは、システム関数を簡単に置換でき、実現するソフトウェアのテストを簡単に指定することができます。たとえば、``sleep()`` 関数を置き換えることができ、実際に 10 分待たずに 10 分のスリープが呼び出されたことを確認します。"

#: ../../rst/dev_guide/testing_units_modules.rst:51
msgid "Unit tests are run on different Python versions. This allows us to ensure that the code behaves in the same way on different Python versions."
msgstr "ユニットテストは、Python の各バージョンで実行されます。これにより、コードが異なる Python のバージョンでも同じように動作することを確認できます。"

#: ../../rst/dev_guide/testing_units_modules.rst:54
msgid "There are also some potential disadvantages of unit tests. Unit tests don't normally directly test actual useful valuable features of software, instead just internal implementation"
msgstr "ユニットテストには、いくつかの潜在的な欠点もあります。通常、実際に便利で価値のある機能を直接テストせず、代わりに内部実装をテストします。"

#: ../../rst/dev_guide/testing_units_modules.rst:58
msgid "Unit tests that test the internal, non-visible features of software may make refactoring difficult if those internal features have to change (see also naming in How below)"
msgstr "ソフトウェア内部にある、目に見えない機能をテストするユニットテストは、それらの内部機能を変更する必要がある場合、リファクタリングを困難にする可能性があります (以下の「方法」の命名も参照)。"

#: ../../rst/dev_guide/testing_units_modules.rst:61
msgid "Even if the internal feature is working correctly it is possible that there will be a problem between the internal code tested and the actual result delivered to the user"
msgstr "内部機能が正しく機能している場合でも、テストされた内部コードとユーザーに配信される実際の結果との間に問題が発生する可能性があります。"

#: ../../rst/dev_guide/testing_units_modules.rst:64
msgid "Normally the Ansible integration tests (which are written in Ansible YAML) provide better testing for most module functionality. If those tests already test a feature and perform well there may be little point in providing a unit test covering the same area as well."
msgstr "通常、(Ansible YAML で記述される) Ansible 統合テストは、ほとんどのモジュール機能に対してより良いテストを提供します。これらのテストがすでに機能をテストしていて、うまく機能している場合は、同じ領域をカバーするユニットテストを提供する意味はほとんどないかもしれません。"

#: ../../rst/dev_guide/testing_units_modules.rst:69
msgid "When To Use Unit Tests"
msgstr "ユニットテストを使用するタイミング"

#: ../../rst/dev_guide/testing_units_modules.rst:71
msgid "There are a number of situations where unit tests are a better choice than integration tests. For example, testing things which are impossible, slow or very difficult to test with integration tests, such as:"
msgstr "統合テストよりもユニットテストの方が適している状況は数多くあります。たとえば、次のような統合テストでテストすることが不可能で、遅い、または非常に難しいものをテストします。"

#: ../../rst/dev_guide/testing_units_modules.rst:75
msgid "Forcing rare / strange / random situations that can't be forced, such as specific network failures and exceptions"
msgstr "特定のネットワーク障害や例外のような、強制することができない稀な、奇妙な、およびランダムな状況を強制。"

#: ../../rst/dev_guide/testing_units_modules.rst:77
msgid "Extensive testing of slow configuration APIs"
msgstr "遅い設定 API の広範なテスト"

#: ../../rst/dev_guide/testing_units_modules.rst:78
msgid "Situations where the integration tests cannot be run as part of the main Ansible continuous integration running in Azure Pipelines."
msgstr "Azure Pipeline で実行されているメインの Ansible 継続的統合の一部として、統合テストを実行できない状況。"

#: ../../rst/dev_guide/testing_units_modules.rst:84
msgid "Providing quick feedback"
msgstr "迅速なフィードバックの提供"

#: ../../rst/dev_guide/testing_units_modules.rst:87
msgid "A single step of the rds_instance test cases can take up to 20 minutes (the time to create an RDS instance in Amazon). The entire test run can last for well over an hour. All 16 of the unit tests complete execution in less than 2 seconds."
msgstr "rds_instance のテストケースの 1 つのステップには、最大 20 分 (Amazonで RDS インスタンスを作成する時間) かかる場合があります。テストの実行は、全体で 1 時間以上かかることもあります。16 個のユニットテストは、すべて 2 秒以内に実行を完了します。"

#: ../../rst/dev_guide/testing_units_modules.rst:92
msgid "The time saving provided by being able to run the code in a unit test makes it worth creating a unit test when bug fixing a module, even if those tests do not often identify problems later. As a basic goal, every module should have at least one unit test which will give quick feedback in easy cases without having to wait for the integration tests to complete."
msgstr "ユニットテストでコードを実行できることによって提供される時間の節約により、モジュールのバグ修正時にユニットテストを作成する価値があります。これらのテストで後で問題が特定されることはあまりありません。基本的な目標として、すべてのモジュールには少なくとも 1 つのユニットテストが必要です。これにより、統合テストが完了するのを待たずに、簡単なケースで迅速なフィードバックが得られます。"

#: ../../rst/dev_guide/testing_units_modules.rst:99
msgid "Ensuring correct use of external interfaces"
msgstr "外部インターフェースを正しく使用すること"

#: ../../rst/dev_guide/testing_units_modules.rst:101
msgid "Unit tests can check the way in which external services are run to ensure that they match specifications or are as efficient as possible *even when the final output will not be changed*."
msgstr "ユニットテストは、*最終的な出力が変更されない場合でも*、外部サービスの実行方法が仕様に合致しているか、あるいは可能な限り効率的であるかを確認できます。"

#: ../../rst/dev_guide/testing_units_modules.rst:105
msgid "Package managers are often far more efficient when installing multiple packages at once rather than each package separately. The final result is the same: the packages are all installed, so the efficiency is difficult to verify through integration tests. By providing a mock package manager and verifying that it is called once, we can build a valuable test for module efficiency."
msgstr "パッケージマネージャーは、各パッケージを個別にインストールするよりも、複数のパッケージを一度にインストールする方がはるかに効率的であることがよくあります。最終結果は同じです。すべてのパッケージがインストールされるため、統合テストで効率を検証することは困難です。模擬パッケージマネージャを提供し、それが一度に呼ばれることを検証するため、モジュール効率について貴重なテストを構築できます。"

#: ../../rst/dev_guide/testing_units_modules.rst:111
msgid "Another related use is in the situation where an API has versions which behave differently. A programmer working on a new version may change the module to work with the new API version and unintentionally break the old version. A test case which checks that the call happens properly for the old version can help avoid the problem. In this situation it is very important to include version numbering in the test case name (see `Naming unit tests`_ below)."
msgstr "別の関連する使用法は、API の動作が異なるバージョンがある状況です。新しいバージョンで作業しているプログラマーは、新しい API バージョンで動作するようにモジュールを変更し、意図せずに古いバージョンを壊してしまう可能性があります。古いバージョンで呼び出しが適切に行われることを確認するテストケースは、問題を回避するのに役立ちます。この状況では、テストケース名にバージョン番号を含めることが非常に重要です (以下 `Naming unit tests`_ を参照)。"

#: ../../rst/dev_guide/testing_units_modules.rst:119
msgid "Providing specific design tests"
msgstr "特定の設計テストの提供"

#: ../../rst/dev_guide/testing_units_modules.rst:121
msgid "By building a requirement for a particular part of the code and then coding to that requirement, unit tests _can_ sometimes improve the code and help future developers understand that code."
msgstr "コードの特定の部分に対する要件を構築し、その要件に合わせてコーディングすることで、ユニットテストは、時にはコードを改善し、将来の開発者がそのコードを理解する助けとなります。"

#: ../../rst/dev_guide/testing_units_modules.rst:125
msgid "Unit tests that test internal implementation details of code, on the other hand, almost always do more harm than good.  Testing that your packages to install are stored in a list would slow down and confuse a future developer who might need to change that list into a dictionary for efficiency. This problem can be reduced somewhat with clear test naming so that the future developer immediately knows to delete the test case, but it is often better to simply leave out the test case altogether and test for a real valuable feature of the code, such as installing all of the packages supplied as arguments to the module."
msgstr "一方、コードの内部実装の詳細をテストするユニットテストは、ほとんどの場合、益よりも害をもたらします。インストールするパッケージがリストに格納されているかどうかをテストすると、遅くなり、効率化のためにリストをディクショナリーに変更しないといけない将来の開発者を混乱させます。この問題は、将来の開発者がすぐにテストケースを削除することがわかるように、明確なテスト名をつけることで多少軽減できますが、単にテストケースを完全に除外して、モジュールの引数として与えられたすべてのパッケージをインストールするなど、コードの本当の価値ある機能をテストする方が良い場合が多いです。"

#: ../../rst/dev_guide/testing_units_modules.rst:135
msgid "How to unit test Ansible modules"
msgstr "Ansible モジュールをユニットテストする方法"

#: ../../rst/dev_guide/testing_units_modules.rst:137
msgid "There are a number of techniques for unit testing modules. Beware that most modules without unit tests are structured in a way that makes testing quite difficult and can lead to very complicated tests which need more work than the code. Effectively using unit tests may lead you to restructure your code. This is often a good thing and leads to better code overall. Good restructuring can make your code clearer and easier to understand."
msgstr "ユニットテストモジュールにはいくつかの手法があります。ユニットテストのないほとんどのモジュールでは、テストが非常に困難になり、コードよりも多くの作業が必要な、非常に複雑なテストにつながる可能性があることに注意してください。ユニットテストを効果的に使用するには、コードを再構築する可能性があります。これは多くの場合良いことであり、全体的に優れたコードにつながります。適切な再構築により、コードがより明確になり、理解しやすくなります。"

#: ../../rst/dev_guide/testing_units_modules.rst:145
msgid "Naming unit tests"
msgstr "ユニットテストの命名"

#: ../../rst/dev_guide/testing_units_modules.rst:147
msgid "Unit tests should have logical names. If a developer working on the module being tested breaks the test case, it should be easy to figure what the unit test covers from the name. If a unit test is designed to verify compatibility with a specific software or API version then include the version in the name of the unit test."
msgstr "ユニットテストは論理名を付ける必要があります。テスト対象のモジュールで作業している開発者がテストケースを壊してしまった場合に、ユニットテストが何を対象としているのかが名前から簡単に分かるようにする必要があります。ユニットテストが特定のソフトウェアや API のバージョンとの互換性を検証するように設計されている場合は、ユニットテストの名前にそのバージョンを追加してください。"

#: ../../rst/dev_guide/testing_units_modules.rst:152
msgid "As an example, ``test_v2_state_present_should_call_create_server_with_name()`` would be a good name, ``test_create_server()`` would not be."
msgstr "たとえば、``test_v2_state_present_should_call_create_server_with_name()`` が適切な名前で、``test_create_server()`` は適切ではありません。"

#: ../../rst/dev_guide/testing_units_modules.rst:157
msgid "Use of Mocks"
msgstr "モックの使用"

#: ../../rst/dev_guide/testing_units_modules.rst:159
msgid "Mock objects (from https://docs.python.org/3/library/unittest.mock.html) can be very useful in building unit tests for special / difficult cases, but they can also lead to complex and confusing coding situations. One good use for mocks would be in simulating an API. As for 'six', the 'mock' python package is bundled with Ansible (use ``import units.compat.mock``)."
msgstr "(https://docs.python.org/3/library/unittest.mock.html_ からの) モックオブジェクトは、特殊なケースや困難なケースのユニットテストを構築するのに非常に便利ですが、複雑で理解しづらいコーディングになってしまうこともあります。モックの使用方法として適切なものの 1 つに、API のシミュレートがあります。Python パッケージの「six」、「mock」は、Ansible にバンドルされています (``import units.compat.mock`` を使用)。"

#: ../../rst/dev_guide/testing_units_modules.rst:166
msgid "Ensuring failure cases are visible with mock objects"
msgstr "モックオブジェクトで障害ケースを確実に可視化"

#: ../../rst/dev_guide/testing_units_modules.rst:168
msgid "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:"
msgstr ":meth:`module.fail_json` などの関数は、通常、実行を終了することが期待されます。モックモジュールオブジェクトを使用して実行すると、モックは常に関数呼び出しから別のモックを返すため、このようなことは起こりません。上記のように例外を発生させるようにモックを設定することもできますし、各テストでこれらの関数が呼び出されていないことをアサートすることもできます。以下に例を示します。"

#: ../../rst/dev_guide/testing_units_modules.rst:179
msgid "This applies not only to calling the main module but almost any other function in a module which gets the module object."
msgstr "これは、メインモジュールを呼び出す場合だけでなく、モジュールオブジェクトを取得するモジュール内の他のほとんどの関数を呼び出す場合にも適用されます。"

#: ../../rst/dev_guide/testing_units_modules.rst:184
msgid "Mocking of the actual module"
msgstr "実際のモジュールのモック化"

#: ../../rst/dev_guide/testing_units_modules.rst:186
msgid "The setup of an actual module is quite complex (see `Passing Arguments`_ below) and often 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:"
msgstr "実際のモジュールの設定は非常に複雑で (以下の `引数の渡し方`_ を参照)、モジュールを使用するほとんどの機能には必要ありません。モックオブジェクトをモジュールとして使用する代わりに、テストする関数で必要なモジュール属性を作成できます。この場合、モジュールの終了関数は、上述のように、例外を発生させるか、呼び出されていないことを確認するなど、特別な処理が必要になることに注意してください。以下に例を示します。"

#: ../../rst/dev_guide/testing_units_modules.rst:207
msgid "API definition with unit test cases"
msgstr "ユニットテストケースでの API 定義"

#: ../../rst/dev_guide/testing_units_modules.rst:209
msgid "API interaction is usually best tested with the function tests defined in Ansible's integration testing section, which run against the actual API. There are several cases where the unit tests are likely to work better."
msgstr "API の対話は通常、実際の API に対して実行する Ansible の統合テストセクションで定義された関数テストでテストを行うのが最適です。ユニットテストが適切に機能する可能性があります。"

#: ../../rst/dev_guide/testing_units_modules.rst:214
msgid "Defining a module against an API specification"
msgstr "API の仕様に対してモジュールを定義"

#: ../../rst/dev_guide/testing_units_modules.rst:216
msgid "This case is especially important for modules interacting with web services, which provide an API that Ansible uses but which are beyond the control of the user."
msgstr "このケースは、Ansible が使用する API を提供しているが、ユーザーの制御が及ばない Web サービスと対話するモジュールにとって特に重要になります。"

#: ../../rst/dev_guide/testing_units_modules.rst:219
msgid "By writing a custom emulation of the calls that return data from the API, we can ensure that only the features which are clearly defined in the specification of the API are present in the message. This means that we can check that we use the correct parameters and nothing else."
msgstr "API からデータを返す呼び出しのカスタムエミュレーションを書くことで、API の仕様で明確に定義されている機能のみがメッセージに含まれていることを確認できます。つまり、正しいパラメーターを使用しているかどうかを確認し、それ以外は何も使用していないことを確認することができます。"

#: ../../rst/dev_guide/testing_units_modules.rst:225
msgid "*Example:  in rds_instance unit tests a simple instance state is defined*:"
msgstr "*例: rds_instance ユニットテストでは、単純なインスタンスの状態が定義されています*。"

#: ../../rst/dev_guide/testing_units_modules.rst:235
msgid "This is then used to create a list of states:"
msgstr "次に、これを使用して状態のリストを作成します。"

#: ../../rst/dev_guide/testing_units_modules.rst:252
msgid "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:"
msgstr "これらの状態は、モックオブジェクトからの戻り値として使用され、``await`` 関数は、RDS インスタンスがまだ設定を完了しないことを意味するすべての状態を待機します。"

#: ../../rst/dev_guide/testing_units_modules.rst:262
msgid "By doing this we check that the ``await`` function will keep waiting through potentially unusual that it would be impossible to reliably trigger through the integration tests but which happen unpredictably in reality."
msgstr "これを実行することで、統合テストでは確実に誘発させることができないにもかかわらず、現実には予測できないような、潜在的に異常なことが起こる可能性がある場合に ``await`` 関数が待機し続けるかどうかを確認します。"

#: ../../rst/dev_guide/testing_units_modules.rst:267
msgid "Defining a module to work against multiple API versions"
msgstr "複数の API バージョンに対して動作するモジュールの定義"

#: ../../rst/dev_guide/testing_units_modules.rst:269
msgid "This case is especially important for modules interacting with many different versions of software; for example, package installation modules that might be expected to work with many different operating system versions."
msgstr "このケースは、多くの異なるバージョンのソフトウェアと対話するモジュールにとって特に重要です。たとえば、さまざまなオペレーティングシステムのバージョンと動作することが想定されるパッケージインストールモジュールなどです。"

#: ../../rst/dev_guide/testing_units_modules.rst:273
msgid "By using previously stored data from various versions of an API we can ensure that the code is tested against the actual data which will be sent from that version of the system even when the version is very obscure and unlikely to be available during testing."
msgstr "さまざまなバージョンの API から、以前に保存されたデータを使用することで、バージョンが非常に曖昧でテスト中に利用できそうにない場合でも、そのバージョンのシステムから送信される実際のデータに対してコードがテストできるようになります。"

#: ../../rst/dev_guide/testing_units_modules.rst:278
msgid "Ansible special cases for unit testing"
msgstr "Ansible ユニットテストの特殊なケース"

#: ../../rst/dev_guide/testing_units_modules.rst:280
msgid "There are a number of special cases for unit testing the environment of an Ansible module. The most common are documented below, and suggestions for others can be found by looking at the source code of the existing unit tests or asking on the Ansible chat channel or mailing lists. For more information on joining chat channels and subscribing to mailing lists, see :ref:`communication`."
msgstr "Ansible モジュールの環境に対してユニットテストを行うための特別なケースがいくつかあります。最も一般的なものを以下に示します。他の人への提案は、既存のユニットテストのソースコードを確認するか、Ansible チャットチャンネルまたはメーリングリストで質問することで見つけることができます。チャットチャンネルへの参加およびメーリングリストのサブスクライブの詳細については、:ref:`communication`を参照してください。"

#: ../../rst/dev_guide/testing_units_modules.rst:286
msgid "Module argument processing"
msgstr "モジュール引数処理"

#: ../../rst/dev_guide/testing_units_modules.rst:288
msgid "There are two problems with running the main function of a module:"
msgstr "モジュールの主な関数の実行には、以下の 2 つの問題があります。"

#: ../../rst/dev_guide/testing_units_modules.rst:290
msgid "Since the module is supposed to accept arguments on ``STDIN`` it is a bit difficult to set up the arguments correctly so that the module will get them as parameters."
msgstr "モジュールは ``STDIN`` で引数を受け入れる必要があるため、引数を正しく設定してモジュールがパラメーターとして受け取るようにするのは少し難しくなります。"

#: ../../rst/dev_guide/testing_units_modules.rst:292
msgid "All modules should finish by calling either the :meth:`module.fail_json` or :meth:`module.exit_json`, but these won't work correctly in a testing environment."
msgstr "すべてのモジュールは、:meth:`module.fail_json` または :meth:`module.exit_json` を呼び出して終了する必要がありますが、テスト環境では正常に動作しません。"

#: ../../rst/dev_guide/testing_units_modules.rst:296
msgid "Passing Arguments"
msgstr "引数の渡し方"

#: ../../rst/dev_guide/testing_units_modules.rst:301
msgid "To pass arguments to a module correctly, use the ``set_module_args`` method which accepts a dictionary 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:"
msgstr "モジュールに正しく引数を渡すには、ディクショナリーをパラメーターとして受け付ける ``set_module_args`` メソッドを使用します。モジュールの作成と引数の処理は、ユーティリティーの基本セクションにある :class:`AnsibleModule` オブジェクトによって処理されます。通常は ``STDIN`` で入力を受け付けますが、これはユニットテストには不便です。特殊変数が設定されると、あたかも入力が ``STDIN`` でモジュールに来たかのように扱われます。モジュールをセットアップする前にこの関数を呼び出すだけです。"

#: ../../rst/dev_guide/testing_units_modules.rst:321
msgid "Handling exit correctly"
msgstr "終了を適切に処理"

#: ../../rst/dev_guide/testing_units_modules.rst:326
msgid "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:"
msgstr ":meth:`module.exit_json` 関数は、終了時にエラー情報を ``STDOUT`` に書き込むため、テスト環境で適切に動作しません。これは検証が困難です。これは、この関数 (および :meth:`module.fail_json`) を、例外を発生させる関数に置き換えることで軽減できます。"

#: ../../rst/dev_guide/testing_units_modules.rst:338
msgid "Now you can ensure that the first function called is the one you expected simply by testing for the correct exception:"
msgstr "これで、正しい例外をテストするだけで、最初に呼び出された関数が期待したものであることを確認できるようになりました。"

#: ../../rst/dev_guide/testing_units_modules.rst:353
msgid "The same technique can be used to replace :meth:`module.fail_json` (which is used for failure returns from modules) and for the ``aws_module.fail_json_aws()`` (used in modules for Amazon Web Services)."
msgstr "同じテクニックを使用して、:meth:`module.fail_json` (モジュールから返る障害に使用) および ``aws_module.fail_json_aws()`` (Amazon Web Services のモジュールに使用) に置き換えることができます。"

#: ../../rst/dev_guide/testing_units_modules.rst:358
msgid "Running the main function"
msgstr "主な関数の実行"

#: ../../rst/dev_guide/testing_units_modules.rst:360
msgid "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:"
msgstr "モジュールにおける主な実関数を実行する場合は、モジュールをインポートし、上記のように引数を設定し、適切な終了例外を設定してからモジュールを実行する必要があります。"

#: ../../rst/dev_guide/testing_units_modules.rst:380
msgid "Handling calls to external executables"
msgstr "外部実行ファイルへの呼び出しの処理"

#: ../../rst/dev_guide/testing_units_modules.rst:382
msgid "Module must use :meth:`AnsibleModule.run_command` in order to execute an external command. This method needs to be mocked:"
msgstr "モジュールは、外部コマンドを実行するのに :meth:`AnsibleModule.run_command` を使用する必要があります。このメソッドをモックする必要があります。"

#: ../../rst/dev_guide/testing_units_modules.rst:385
msgid "Here is a simple mock of :meth:`AnsibleModule.run_command` (taken from :file:`test/units/modules/packaging/os/test_rhn_register.py`):"
msgstr "以下は、:meth:`AnsibleModule.run_command` (:file:`test/units/modules/packaging/os/test_rhn_register.py` から取得) の簡単なモックです。"

#: ../../rst/dev_guide/testing_units_modules.rst:401
msgid "A Complete Example"
msgstr "完全な例"

#: ../../rst/dev_guide/testing_units_modules.rst:403
msgid "The following example is a complete skeleton that reuses the mocks explained above and adds a new mock for :meth:`Ansible.get_bin_path`:"
msgstr "次の例は、上記で説明したモックを再利用し、:meth:`Ansible.get_bin_path` の新しいモックを追加する完全なスケルトンです。"

#: ../../rst/dev_guide/testing_units_modules.rst:491
msgid "Restructuring modules to enable testing module set up and other processes"
msgstr "モジュールのセットアップやその他のプロセスのテストを可能にするモジュールの再構築"

#: ../../rst/dev_guide/testing_units_modules.rst:493
msgid "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:"
msgstr "多くの場合、モジュールをセットアップし、他のアクションを実行する ``main()`` 関数があります。これにより、引数処理を確認するのが困難になる可能性があります。モジュールの設定と初期化を別の関数に移すことで簡単にできます。以下に例を示します。"

#: ../../rst/dev_guide/testing_units_modules.rst:525
msgid "This now makes it possible to run tests against the module initiation function:"
msgstr "これにより、モジュールの開始関数に対してテストを実行できるようになりました。"

#: ../../rst/dev_guide/testing_units_modules.rst:539
msgid "See also ``test/units/module_utils/aws/test_rds.py``"
msgstr "「``test/units/module_utils/aws/test_rds.py``」も参照してください。"

#: ../../rst/dev_guide/testing_units_modules.rst:541
msgid "Note that the ``argument_spec`` dictionary is visible in a module variable. This has advantages, both in allowing explicit testing of the arguments and in allowing the easy creation of module objects for testing."
msgstr "``argument_spec`` ディクショナリーはモジュール変数に表示されます。これには、引数の明示的なテストを許可し、テスト用にモジュールオブジェクトの作成を簡単に行えるようにする利点があります。"

#: ../../rst/dev_guide/testing_units_modules.rst:545
msgid "The same restructuring technique can be valuable for testing other functionality, such as the part of the module which queries the object that the module configures."
msgstr "この再構築の手法は、モジュールが設定したオブジェクトを問い合わせるモジュールの部分など、その他の機能をテストする場合にも役に立ちます。"

#: ../../rst/dev_guide/testing_units_modules.rst:548
msgid "Traps for maintaining Python 2 compatibility"
msgstr "Python 2 の互換性を維持するためのトラップ"

#: ../../rst/dev_guide/testing_units_modules.rst:550
msgid "If you use the ``mock`` library from the Python 2.6 standard library, a number of the assert functions are missing but will return as if successful. This means that test cases should take great care *not* use functions marked as _new_ in the Python 3 documentation, since the tests will likely always succeed even if the code is broken when run on older versions of Python."
msgstr "Python 2.6 標準ライブラリーの ``mock`` ライブラリーを使用している場合は、多くの assert 関数が欠落していますが、成功したかのように返されます。これは、テストケースが、Python 3 のドキュメントで _new_ となっている関数を使用しないよう、細心の注意を払うべきであることを意味します。なぜなら、古いバージョンの Python で実行されたコードが壊れていても、テストは常に成功するからです。"

#: ../../rst/dev_guide/testing_units_modules.rst:555
msgid "A helpful development approach to this should be to ensure that all of the tests have been run under Python 2.6 and that each assertion in the test cases has been checked to work by breaking the code in Ansible to trigger that failure."
msgstr "これに役立つ開発アプローチは、すべてのテストが Python 2.6 で実行されていることと、テストケース内の各アサーションが Ansible でコードを壊してその失敗を誘発することで動作することが確認されているという点を確認することです。"

#: ../../rst/dev_guide/testing_units_modules.rst:559
msgid "Maintain Python 2.6 compatibility"
msgstr "Python 2.6 互換性の維持"

#: ../../rst/dev_guide/testing_units_modules.rst:561
msgid "Please remember that modules need to maintain compatibility with Python 2.6 so the unittests for modules should also be compatible with Python 2.6."
msgstr "モジュールは Python 2.6 との互換性を維持する必要があるため、モジュールのユニットテストも、Python 2.6 との互換性を維持する必要があることに注意してください。"

#: ../../rst/dev_guide/testing_units_modules.rst:568
msgid "Ansible unit tests documentation"
msgstr "Ansible ユニットテストドキュメント"

#: ../../rst/dev_guide/testing_units_modules.rst:572
msgid "Get started developing a module"
msgstr "モジュール開発を始める"

#: ../../rst/dev_guide/testing_units_modules.rst:581
msgid "`Testing Your Code (from The Hitchhiker's Guide to Python!) <https://docs.python-guide.org/writing/tests/>`_"
msgstr "`Testing Your Code (from The Hitchhiker's Guide to Python!) <https://docs.python-guide.org/writing/tests/>`_"

#: ../../rst/dev_guide/testing_units_modules.rst:582
msgid "General advice on testing Python code"
msgstr "Python コードのテストに関する一般的なアドバイス"

#: ../../rst/dev_guide/testing_units_modules.rst:584
msgid "`Uncle Bob's many videos on YouTube <https://www.youtube.com/watch?v=QedpQjxBPMA&list=PLlu0CT-JnSasQzGrGzddSczJQQU7295D2>`_"
msgstr "`Uncle Bob's many videos on YouTube <https://www.youtube.com/watch?v=QedpQjxBPMA&list=PLlu0CT-JnSasQzGrGzddSczJQQU7295D2>`_"

#: ../../rst/dev_guide/testing_units_modules.rst:584
msgid "Unit testing is a part of the of various philosophies of software development, including Extreme Programming (XP), Clean Coding.  Uncle Bob talks through how to benefit from this"
msgstr "ユニットテストは、Extreme Programming (XP)、クリーンコーディングを含むソフトウェア開発のさまざまな哲学の一部です。Uncle Bob は、どのようにしてこの恩恵を受けることができるのかを説明します。"

#: ../../rst/dev_guide/testing_units_modules.rst:586
msgid "`\"Why Most Unit Testing is Waste\" <https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf>`_"
msgstr "`\"Why Most Unit Testing is Waste\" <https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf>`_"

#: ../../rst/dev_guide/testing_units_modules.rst:587
msgid "An article warning against the costs of unit testing"
msgstr "ユニットテストの大半が無駄である理由"

#: ../../rst/dev_guide/testing_units_modules.rst:588
msgid "`'A Response to \"Why Most Unit Testing is Waste\"' <https://henrikwarne.com/2014/09/04/a-response-to-why-most-unit-testing-is-waste/>`_"
msgstr "`'A Response to \"Why Most Unit Testing is Waste\"' <https://henrikwarne.com/2014/09/04/a-response-to-why-most-unit-testing-is-waste/>`_"

#: ../../rst/dev_guide/testing_units_modules.rst:589
msgid "An response pointing to how to maintain the value of unit tests"
msgstr "ユニットテストの価値を維持する方法を指摘した回答"

#: ../../rst/dev_guide/testing_validate-modules.rst:11
msgid "Python program to help test or validate Ansible modules."
msgstr "Ansible モジュールのテストまたは検証に役立つ Python プログラム。"

#: ../../rst/dev_guide/testing_validate-modules.rst:13
msgid "``validate-modules`` is one of the ``ansible-test`` Sanity Tests, see :ref:`testing_sanity` for more information."
msgstr "``validate-modules`` は、健全性テスト ``ansible-test`` のいずれかです。詳細は、「:ref:`testing_sanity`」を参照してください。"

#: ../../rst/dev_guide/testing_validate-modules.rst:15
msgid "Originally developed by Matt Martz (@sivel)"
msgstr "本プログラムは、元々 Matt Martz (@sivel) 氏により開発されました。"

#: ../../rst/dev_guide/testing_validate-modules.rst:19
msgid "Usage"
msgstr "使用法"

#: ../../rst/dev_guide/testing_validate-modules.rst:28
msgid "Help"
msgstr "ヘルプ"

#: ../../rst/dev_guide/testing_validate-modules.rst:53
msgid "Extending validate-modules"
msgstr "validate-modules の拡張"

#: ../../rst/dev_guide/testing_validate-modules.rst:55
msgid "The ``validate-modules`` tool has a `schema.py <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_util/controller/sanity/validate-modules/validate_modules/schema.py>`_ that is used to validate the YAML blocks, such as ``DOCUMENTATION`` and ``RETURNS``."
msgstr "``validate-modules`` ツールには、``DOCUMENTATION``、``RETURNS`` などの YAML ブロックの検証に使用される `schema.py <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_util/controller/sanity/validate-modules/validate_modules/schema.py>`_ があります。"

#: ../../rst/dev_guide/testing_validate-modules.rst:59
msgid "Codes"
msgstr "コード"

#: ../../rst/dev_guide/testing_validate-modules.rst:62
msgid "**Error Code**"
msgstr "**エラーコード**"

#: ../../rst/dev_guide/testing_validate-modules.rst:62
msgid "**Type**"
msgstr "**タイプ**"

#: ../../rst/dev_guide/testing_validate-modules.rst:62
msgid "**Level**"
msgstr "**レベル**"

#: ../../rst/dev_guide/testing_validate-modules.rst:62
msgid "**Sample Message**"
msgstr "**開始メッセージ**"

#: ../../rst/dev_guide/testing_validate-modules.rst:64
msgid "ansible-deprecated-module"
msgstr "ansible-deprecated-module"

#: ../../rst/dev_guide/testing_validate-modules.rst:64
#: ../../rst/dev_guide/testing_validate-modules.rst:65
#: ../../rst/dev_guide/testing_validate-modules.rst:66
#: ../../rst/dev_guide/testing_validate-modules.rst:68
#: ../../rst/dev_guide/testing_validate-modules.rst:69
#: ../../rst/dev_guide/testing_validate-modules.rst:70
#: ../../rst/dev_guide/testing_validate-modules.rst:71
#: ../../rst/dev_guide/testing_validate-modules.rst:72
#: ../../rst/dev_guide/testing_validate-modules.rst:73
#: ../../rst/dev_guide/testing_validate-modules.rst:74
#: ../../rst/dev_guide/testing_validate-modules.rst:75
#: ../../rst/dev_guide/testing_validate-modules.rst:76
#: ../../rst/dev_guide/testing_validate-modules.rst:77
#: ../../rst/dev_guide/testing_validate-modules.rst:78
#: ../../rst/dev_guide/testing_validate-modules.rst:79
#: ../../rst/dev_guide/testing_validate-modules.rst:80
#: ../../rst/dev_guide/testing_validate-modules.rst:81
#: ../../rst/dev_guide/testing_validate-modules.rst:84
#: ../../rst/dev_guide/testing_validate-modules.rst:87
#: ../../rst/dev_guide/testing_validate-modules.rst:88
#: ../../rst/dev_guide/testing_validate-modules.rst:89
#: ../../rst/dev_guide/testing_validate-modules.rst:90
#: ../../rst/dev_guide/testing_validate-modules.rst:91
#: ../../rst/dev_guide/testing_validate-modules.rst:92
#: ../../rst/dev_guide/testing_validate-modules.rst:93
#: ../../rst/dev_guide/testing_validate-modules.rst:94
#: ../../rst/dev_guide/testing_validate-modules.rst:95
#: ../../rst/dev_guide/testing_validate-modules.rst:97
#: ../../rst/dev_guide/testing_validate-modules.rst:98
#: ../../rst/dev_guide/testing_validate-modules.rst:100
#: ../../rst/dev_guide/testing_validate-modules.rst:101
#: ../../rst/dev_guide/testing_validate-modules.rst:102
#: ../../rst/dev_guide/testing_validate-modules.rst:103
#: ../../rst/dev_guide/testing_validate-modules.rst:104
#: ../../rst/dev_guide/testing_validate-modules.rst:109
#: ../../rst/dev_guide/testing_validate-modules.rst:110
#: ../../rst/dev_guide/testing_validate-modules.rst:111
#: ../../rst/dev_guide/testing_validate-modules.rst:112
#: ../../rst/dev_guide/testing_validate-modules.rst:113
#: ../../rst/dev_guide/testing_validate-modules.rst:117
#: ../../rst/dev_guide/testing_validate-modules.rst:119
#: ../../rst/dev_guide/testing_validate-modules.rst:120
#: ../../rst/dev_guide/testing_validate-modules.rst:121
#: ../../rst/dev_guide/testing_validate-modules.rst:122
#: ../../rst/dev_guide/testing_validate-modules.rst:123
#: ../../rst/dev_guide/testing_validate-modules.rst:124
#: ../../rst/dev_guide/testing_validate-modules.rst:125
#: ../../rst/dev_guide/testing_validate-modules.rst:128
#: ../../rst/dev_guide/testing_validate-modules.rst:132
#: ../../rst/dev_guide/testing_validate-modules.rst:133
#: ../../rst/dev_guide/testing_validate-modules.rst:134
#: ../../rst/dev_guide/testing_validate-modules.rst:137
#: ../../rst/dev_guide/testing_validate-modules.rst:139
#: ../../rst/dev_guide/testing_validate-modules.rst:145
#: ../../rst/dev_guide/testing_validate-modules.rst:146
#: ../../rst/dev_guide/testing_validate-modules.rst:147
#: ../../rst/dev_guide/testing_validate-modules.rst:148
#: ../../rst/dev_guide/testing_validate-modules.rst:149
#: ../../rst/dev_guide/testing_validate-modules.rst:150
#: ../../rst/dev_guide/testing_validate-modules.rst:151
#: ../../rst/dev_guide/testing_validate-modules.rst:152
#: ../../rst/dev_guide/testing_validate-modules.rst:153
#: ../../rst/dev_guide/testing_validate-modules.rst:154
#: ../../rst/dev_guide/testing_validate-modules.rst:155
#: ../../rst/dev_guide/testing_validate-modules.rst:156
#: ../../rst/dev_guide/testing_validate-modules.rst:157
#: ../../rst/dev_guide/testing_validate-modules.rst:158
#: ../../rst/dev_guide/testing_validate-modules.rst:159
#: ../../rst/dev_guide/testing_validate-modules.rst:160
#: ../../rst/dev_guide/testing_validate-modules.rst:161
#: ../../rst/dev_guide/testing_validate-modules.rst:162
#: ../../rst/dev_guide/testing_validate-modules.rst:163
#: ../../rst/dev_guide/testing_validate-modules.rst:164
msgid "Documentation"
msgstr "ドキュメント"

#: ../../rst/dev_guide/testing_validate-modules.rst:64
#: ../../rst/dev_guide/testing_validate-modules.rst:65
#: ../../rst/dev_guide/testing_validate-modules.rst:66
#: ../../rst/dev_guide/testing_validate-modules.rst:67
#: ../../rst/dev_guide/testing_validate-modules.rst:68
#: ../../rst/dev_guide/testing_validate-modules.rst:69
#: ../../rst/dev_guide/testing_validate-modules.rst:70
#: ../../rst/dev_guide/testing_validate-modules.rst:71
#: ../../rst/dev_guide/testing_validate-modules.rst:72
#: ../../rst/dev_guide/testing_validate-modules.rst:73
#: ../../rst/dev_guide/testing_validate-modules.rst:74
#: ../../rst/dev_guide/testing_validate-modules.rst:75
#: ../../rst/dev_guide/testing_validate-modules.rst:76
#: ../../rst/dev_guide/testing_validate-modules.rst:77
#: ../../rst/dev_guide/testing_validate-modules.rst:78
#: ../../rst/dev_guide/testing_validate-modules.rst:79
#: ../../rst/dev_guide/testing_validate-modules.rst:80
#: ../../rst/dev_guide/testing_validate-modules.rst:81
#: ../../rst/dev_guide/testing_validate-modules.rst:82
#: ../../rst/dev_guide/testing_validate-modules.rst:83
#: ../../rst/dev_guide/testing_validate-modules.rst:84
#: ../../rst/dev_guide/testing_validate-modules.rst:86
#: ../../rst/dev_guide/testing_validate-modules.rst:87
#: ../../rst/dev_guide/testing_validate-modules.rst:88
#: ../../rst/dev_guide/testing_validate-modules.rst:89
#: ../../rst/dev_guide/testing_validate-modules.rst:90
#: ../../rst/dev_guide/testing_validate-modules.rst:91
#: ../../rst/dev_guide/testing_validate-modules.rst:92
#: ../../rst/dev_guide/testing_validate-modules.rst:93
#: ../../rst/dev_guide/testing_validate-modules.rst:94
#: ../../rst/dev_guide/testing_validate-modules.rst:95
#: ../../rst/dev_guide/testing_validate-modules.rst:96
#: ../../rst/dev_guide/testing_validate-modules.rst:97
#: ../../rst/dev_guide/testing_validate-modules.rst:98
#: ../../rst/dev_guide/testing_validate-modules.rst:99
#: ../../rst/dev_guide/testing_validate-modules.rst:100
#: ../../rst/dev_guide/testing_validate-modules.rst:102
#: ../../rst/dev_guide/testing_validate-modules.rst:103
#: ../../rst/dev_guide/testing_validate-modules.rst:104
#: ../../rst/dev_guide/testing_validate-modules.rst:106
#: ../../rst/dev_guide/testing_validate-modules.rst:107
#: ../../rst/dev_guide/testing_validate-modules.rst:108
#: ../../rst/dev_guide/testing_validate-modules.rst:109
#: ../../rst/dev_guide/testing_validate-modules.rst:111
#: ../../rst/dev_guide/testing_validate-modules.rst:112
#: ../../rst/dev_guide/testing_validate-modules.rst:113
#: ../../rst/dev_guide/testing_validate-modules.rst:114
#: ../../rst/dev_guide/testing_validate-modules.rst:115
#: ../../rst/dev_guide/testing_validate-modules.rst:116
#: ../../rst/dev_guide/testing_validate-modules.rst:117
#: ../../rst/dev_guide/testing_validate-modules.rst:118
#: ../../rst/dev_guide/testing_validate-modules.rst:119
#: ../../rst/dev_guide/testing_validate-modules.rst:120
#: ../../rst/dev_guide/testing_validate-modules.rst:121
#: ../../rst/dev_guide/testing_validate-modules.rst:122
#: ../../rst/dev_guide/testing_validate-modules.rst:123
#: ../../rst/dev_guide/testing_validate-modules.rst:124
#: ../../rst/dev_guide/testing_validate-modules.rst:125
#: ../../rst/dev_guide/testing_validate-modules.rst:126
#: ../../rst/dev_guide/testing_validate-modules.rst:127
#: ../../rst/dev_guide/testing_validate-modules.rst:128
#: ../../rst/dev_guide/testing_validate-modules.rst:129
#: ../../rst/dev_guide/testing_validate-modules.rst:130
#: ../../rst/dev_guide/testing_validate-modules.rst:131
#: ../../rst/dev_guide/testing_validate-modules.rst:132
#: ../../rst/dev_guide/testing_validate-modules.rst:133
#: ../../rst/dev_guide/testing_validate-modules.rst:134
#: ../../rst/dev_guide/testing_validate-modules.rst:135
#: ../../rst/dev_guide/testing_validate-modules.rst:137
#: ../../rst/dev_guide/testing_validate-modules.rst:138
#: ../../rst/dev_guide/testing_validate-modules.rst:140
#: ../../rst/dev_guide/testing_validate-modules.rst:141
#: ../../rst/dev_guide/testing_validate-modules.rst:142
#: ../../rst/dev_guide/testing_validate-modules.rst:143
#: ../../rst/dev_guide/testing_validate-modules.rst:144
#: ../../rst/dev_guide/testing_validate-modules.rst:145
#: ../../rst/dev_guide/testing_validate-modules.rst:146
#: ../../rst/dev_guide/testing_validate-modules.rst:147
#: ../../rst/dev_guide/testing_validate-modules.rst:148
#: ../../rst/dev_guide/testing_validate-modules.rst:149
#: ../../rst/dev_guide/testing_validate-modules.rst:150
#: ../../rst/dev_guide/testing_validate-modules.rst:151
#: ../../rst/dev_guide/testing_validate-modules.rst:152
#: ../../rst/dev_guide/testing_validate-modules.rst:153
#: ../../rst/dev_guide/testing_validate-modules.rst:154
#: ../../rst/dev_guide/testing_validate-modules.rst:155
#: ../../rst/dev_guide/testing_validate-modules.rst:156
#: ../../rst/dev_guide/testing_validate-modules.rst:157
#: ../../rst/dev_guide/testing_validate-modules.rst:158
#: ../../rst/dev_guide/testing_validate-modules.rst:159
#: ../../rst/dev_guide/testing_validate-modules.rst:160
#: ../../rst/dev_guide/testing_validate-modules.rst:161
#: ../../rst/dev_guide/testing_validate-modules.rst:162
#: ../../rst/dev_guide/testing_validate-modules.rst:163
#: ../../rst/dev_guide/testing_validate-modules.rst:164
msgid "Error"
msgstr "エラー"

#: ../../rst/dev_guide/testing_validate-modules.rst:64
msgid "A module is deprecated and supposed to be removed in the current or an earlier Ansible version"
msgstr "モジュールは非推奨となり、現行またはそれ以前の Ansible バージョンで削除される予定です。"

#: ../../rst/dev_guide/testing_validate-modules.rst:65
msgid "collection-deprecated-module"
msgstr "collection-deprecated-module"

#: ../../rst/dev_guide/testing_validate-modules.rst:65
msgid "A module is deprecated and supposed to be removed in the current or an earlier collection version"
msgstr "モジュールは非推奨となり、現行またはそれ以前のバージョンのコレクションで削除される予定です。"

#: ../../rst/dev_guide/testing_validate-modules.rst:66
msgid "ansible-deprecated-version"
msgstr "ansible-deprecated-version"

#: ../../rst/dev_guide/testing_validate-modules.rst:66
msgid "A feature is deprecated and supposed to be removed in the current or an earlier Ansible version"
msgstr "機能は非推奨となり、現行またはそれ以前の Ansible バージョンで削除される予定です。"

#: ../../rst/dev_guide/testing_validate-modules.rst:67
msgid "ansible-module-not-initialized"
msgstr "ansible-module-not-initialized"

#: ../../rst/dev_guide/testing_validate-modules.rst:67
#: ../../rst/dev_guide/testing_validate-modules.rst:107
#: ../../rst/dev_guide/testing_validate-modules.rst:108
#: ../../rst/dev_guide/testing_validate-modules.rst:131
#: ../../rst/dev_guide/testing_validate-modules.rst:138
msgid "Syntax"
msgstr "構文"

#: ../../rst/dev_guide/testing_validate-modules.rst:67
msgid "Execution of the module did not result in initialization of AnsibleModule"
msgstr "モジュールを実行しても、AnsibleModule は初期化されなかった。"

#: ../../rst/dev_guide/testing_validate-modules.rst:68
msgid "collection-deprecated-version"
msgstr "collection-deprecated-version"

#: ../../rst/dev_guide/testing_validate-modules.rst:68
msgid "A feature is deprecated and supposed to be removed in the current or an earlier collection version"
msgstr "機能は非推奨となり、現行またはそれ以前のバージョンのコレクションで削除される予定です。"

#: ../../rst/dev_guide/testing_validate-modules.rst:69
msgid "deprecated-date"
msgstr "deprecated-date"

#: ../../rst/dev_guide/testing_validate-modules.rst:69
msgid "A date before today appears as ``removed_at_date`` or in ``deprecated_aliases``"
msgstr "今日より前の日付は、``removed_at_date`` ように表示されるか、``deprecated_aliases`` に表示されます。"

#: ../../rst/dev_guide/testing_validate-modules.rst:70
msgid "deprecation-mismatch"
msgstr "deprecation-mismatch"

#: ../../rst/dev_guide/testing_validate-modules.rst:70
msgid "Module marked as deprecated or removed in at least one of the filename, its metadata, or in DOCUMENTATION (setting DOCUMENTATION.deprecated for deprecation or removing all Documentation for removed) but not in all three places."
msgstr "ファイル名、そのメタデータ、または DOCUMENTATION の少なくとも 1 つ (全箇所ではない) で非推奨または削除済みとしてマークされたモジュール (非推奨の場合は DOCUMENTATION.deprecated を設定し、削除の場合はすべてのドキュメントを削除する) します。"

#: ../../rst/dev_guide/testing_validate-modules.rst:71
msgid "doc-choices-do-not-match-spec"
msgstr "doc-choices-do-not-match-spec"

#: ../../rst/dev_guide/testing_validate-modules.rst:71
msgid "Value for \"choices\" from the argument_spec does not match the documentation"
msgstr "argument_spec の「choices」の値がドキュメントと一致しない。"

#: ../../rst/dev_guide/testing_validate-modules.rst:72
msgid "doc-choices-incompatible-type"
msgstr "doc-choices-incompatible-type"

#: ../../rst/dev_guide/testing_validate-modules.rst:72
msgid "Choices value from the documentation is not compatible with type defined in the argument_spec"
msgstr "ドキュメンテーションの選択値は、argument_spec で定義されたタイプと互換性がありません。"

#: ../../rst/dev_guide/testing_validate-modules.rst:73
msgid "doc-default-does-not-match-spec"
msgstr "doc-default-does-not-match-spec"

#: ../../rst/dev_guide/testing_validate-modules.rst:73
msgid "Value for \"default\" from the argument_spec does not match the documentation"
msgstr "argument_spec の「default」の値がドキュメントと一致しない。"

#: ../../rst/dev_guide/testing_validate-modules.rst:74
msgid "doc-default-incompatible-type"
msgstr "doc-default-incompatible-type"

#: ../../rst/dev_guide/testing_validate-modules.rst:74
msgid "Default value from the documentation is not compatible with type defined in the argument_spec"
msgstr "ドキュメンテーションのデフォルト値は、argument_spec で定義されたタイプと互換性がありません。"

#: ../../rst/dev_guide/testing_validate-modules.rst:75
msgid "doc-elements-invalid"
msgstr "doc-elements-invalid"

#: ../../rst/dev_guide/testing_validate-modules.rst:75
msgid "Documentation specifies elements for argument, when \"type\" is not ``list``."
msgstr "ドキュメントでは、「type」が ``list`` ではない場合に、引数の要素を指定します。"

#: ../../rst/dev_guide/testing_validate-modules.rst:76
msgid "doc-elements-mismatch"
msgstr "doc-elements-mismatch"

#: ../../rst/dev_guide/testing_validate-modules.rst:76
msgid "Argument_spec defines elements different than documentation does"
msgstr "argument_spec はドキュメントとは異なるタイプを定義します。"

#: ../../rst/dev_guide/testing_validate-modules.rst:77
msgid "doc-missing-type"
msgstr "doc-missing-type"

#: ../../rst/dev_guide/testing_validate-modules.rst:77
msgid "Documentation doesn't specify a type but argument in ``argument_spec`` use default type (``str``)"
msgstr "ドキュメントではタイプをしていませんが、``argument_spec`` の引数がデフォルト型 (``str``) を使用しています。"

#: ../../rst/dev_guide/testing_validate-modules.rst:78
msgid "doc-required-mismatch"
msgstr "doc-required-mismatch"

#: ../../rst/dev_guide/testing_validate-modules.rst:78
msgid "argument in argument_spec is required but documentation says it is not, or vice versa"
msgstr "arguments_spec の引数は必須ですが、ドキュメントには必須ではない (または arguments_spec の引数は必須ではありませんが、ドキュメントには必須) と記載されています。"

#: ../../rst/dev_guide/testing_validate-modules.rst:79
msgid "doc-type-does-not-match-spec"
msgstr "doc-type-does-not-match-spec"

#: ../../rst/dev_guide/testing_validate-modules.rst:79
msgid "Argument_spec defines type different than documentation does"
msgstr "argument_spec がドキュメントとは異なるタイプを定義します。"

#: ../../rst/dev_guide/testing_validate-modules.rst:80
msgid "documentation-error"
msgstr "documentation-error"

#: ../../rst/dev_guide/testing_validate-modules.rst:80
msgid "Unknown ``DOCUMENTATION`` error"
msgstr "不明な ``DOCUMENTATION`` エラー"

#: ../../rst/dev_guide/testing_validate-modules.rst:81
msgid "documentation-syntax-error"
msgstr "documentation-syntax-error"

#: ../../rst/dev_guide/testing_validate-modules.rst:81
msgid "Invalid ``DOCUMENTATION`` schema"
msgstr "無効な ``DOCUMENTATION`` スキーマ"

#: ../../rst/dev_guide/testing_validate-modules.rst:82
msgid "illegal-future-imports"
msgstr "illegal-future-imports"

#: ../../rst/dev_guide/testing_validate-modules.rst:82
#: ../../rst/dev_guide/testing_validate-modules.rst:83
#: ../../rst/dev_guide/testing_validate-modules.rst:86
#: ../../rst/dev_guide/testing_validate-modules.rst:105
#: ../../rst/dev_guide/testing_validate-modules.rst:106
#: ../../rst/dev_guide/testing_validate-modules.rst:114
#: ../../rst/dev_guide/testing_validate-modules.rst:115
#: ../../rst/dev_guide/testing_validate-modules.rst:116
#: ../../rst/dev_guide/testing_validate-modules.rst:136
#: ../../rst/dev_guide/testing_validate-modules.rst:140
#: ../../rst/dev_guide/testing_validate-modules.rst:141
#: ../../rst/dev_guide/testing_validate-modules.rst:142
#: ../../rst/dev_guide/testing_validate-modules.rst:143
#: ../../rst/dev_guide/testing_validate-modules.rst:144
msgid "Imports"
msgstr "インポート"

#: ../../rst/dev_guide/testing_validate-modules.rst:82
msgid "Only the following ``from __future__`` imports are allowed: ``absolute_import``, ``division``, and ``print_function``."
msgstr "``absolute_import``、``division``、および ``print_function`` の ``from __future__`` インポートのみが許可されます。"

#: ../../rst/dev_guide/testing_validate-modules.rst:83
msgid "import-before-documentation"
msgstr "import-before-documentation"

#: ../../rst/dev_guide/testing_validate-modules.rst:83
msgid "Import found before documentation variables. All imports must appear below ``DOCUMENTATION``/``EXAMPLES``/``RETURN``"
msgstr "ドキュメント変数の前にインポートが見つかりました。すべてのインポートは、``DOCUMENTATION``/``EXAMPLES``/``RETURN`` の下に表示される必要があります。"

#: ../../rst/dev_guide/testing_validate-modules.rst:84
msgid "import-error"
msgstr "import-error"

#: ../../rst/dev_guide/testing_validate-modules.rst:84
msgid "``Exception`` attempting to import module for ``argument_spec`` introspection"
msgstr "``Exception`` が、``argument_spec`` イントロスペクションのモジュールのインポートを試行中"

#: ../../rst/dev_guide/testing_validate-modules.rst:85
msgid "import-placement"
msgstr "import-placement"

#: ../../rst/dev_guide/testing_validate-modules.rst:85
msgid "Locations"
msgstr "場所"

#: ../../rst/dev_guide/testing_validate-modules.rst:85
#: ../../rst/dev_guide/testing_validate-modules.rst:101
#: ../../rst/dev_guide/testing_validate-modules.rst:105
#: ../../rst/dev_guide/testing_validate-modules.rst:110
#: ../../rst/dev_guide/testing_validate-modules.rst:136
#: ../../rst/dev_guide/testing_validate-modules.rst:139
msgid "Warning"
msgstr "警告"

#: ../../rst/dev_guide/testing_validate-modules.rst:85
#: ../../rst/dev_guide/testing_validate-modules.rst:86
msgid "Imports should be directly below ``DOCUMENTATION``/``EXAMPLES``/``RETURN``"
msgstr "インポートは、``DOCUMENTATION``/``EXAMPLES``/``RETURN`` のすぐ後に配置しなければなりません。"

#: ../../rst/dev_guide/testing_validate-modules.rst:86
msgid "imports-improper-location"
msgstr "imports-improper-location"

#: ../../rst/dev_guide/testing_validate-modules.rst:87
msgid "incompatible-choices"
msgstr "incompatible-choices"

#: ../../rst/dev_guide/testing_validate-modules.rst:87
msgid "Choices value from the argument_spec is not compatible with type defined in the argument_spec"
msgstr "argument_spec の選択値は、argument_spec で定義されたタイプと互換性がありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:88
msgid "incompatible-default-type"
msgstr "incompatible-default-type"

#: ../../rst/dev_guide/testing_validate-modules.rst:88
msgid "Default value from the argument_spec is not compatible with type defined in the argument_spec"
msgstr "argument_spec のデフォルト値は、argument_spec で定義されたタイプと互換性がありません。"

#: ../../rst/dev_guide/testing_validate-modules.rst:89
msgid "invalid-argument-name"
msgstr "invalid-argument-name"

#: ../../rst/dev_guide/testing_validate-modules.rst:89
msgid "Argument in argument_spec must not be one of 'message', 'syslog_facility' as it is used internally by Ansible Core Engine"
msgstr "argument_spec の引数は、Ansible Core Engine によって内部で使用されるため、「message」、「syslog_facility」のいずれかにすることはできません。"

#: ../../rst/dev_guide/testing_validate-modules.rst:90
msgid "invalid-argument-spec"
msgstr "invalid-argument-spec"

#: ../../rst/dev_guide/testing_validate-modules.rst:90
msgid "Argument in argument_spec must be a dictionary/hash when used"
msgstr "argument_spec の引数を使用する場合は、ディクショナリーまたはハッシュである必要があります。"

#: ../../rst/dev_guide/testing_validate-modules.rst:91
msgid "invalid-argument-spec-options"
msgstr "invalid-argument-spec-options"

#: ../../rst/dev_guide/testing_validate-modules.rst:91
msgid "Suboptions in argument_spec are invalid"
msgstr "argument_spec のサブオプションは無効です。"

#: ../../rst/dev_guide/testing_validate-modules.rst:92
msgid "invalid-documentation"
msgstr "invalid-documentation"

#: ../../rst/dev_guide/testing_validate-modules.rst:92
msgid "``DOCUMENTATION`` is not valid YAML"
msgstr "``DOCUMENTATION`` は、有効な YAML ではありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:93
msgid "invalid-documentation-markup"
msgstr "invalid-documentation-markup"

#: ../../rst/dev_guide/testing_validate-modules.rst:93
msgid "``DOCUMENTATION`` or ``RETURN`` contains invalid markup"
msgstr "``DOCUMENTATION`` または、``RETURN`` に無効なマークアップが含まれています"

#: ../../rst/dev_guide/testing_validate-modules.rst:94
msgid "invalid-documentation-options"
msgstr "invalid-documentation-options"

#: ../../rst/dev_guide/testing_validate-modules.rst:94
msgid "``DOCUMENTATION.options`` must be a dictionary/hash when used"
msgstr "``DOCUMENTATION.options`` を使用する場合は、ディクショナリー/ハッシュでなければなりません"

#: ../../rst/dev_guide/testing_validate-modules.rst:95
msgid "invalid-examples"
msgstr "invalid-examples"

#: ../../rst/dev_guide/testing_validate-modules.rst:95
msgid "``EXAMPLES`` is not valid YAML"
msgstr "``EXAMPLES`` は、有効な YAML ではありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:96
msgid "invalid-extension"
msgstr "invalid-extension"

#: ../../rst/dev_guide/testing_validate-modules.rst:96
#: ../../rst/dev_guide/testing_validate-modules.rst:99
#: ../../rst/dev_guide/testing_validate-modules.rst:135
msgid "Naming"
msgstr "命名規則"

#: ../../rst/dev_guide/testing_validate-modules.rst:96
msgid "Official Ansible modules must have a ``.py`` extension for python modules or a ``.ps1`` for powershell modules"
msgstr "公式の Ansible モジュールでは、python モジュールの拡張子は ``.py`` で、powershell モジュールの拡張子は ``.ps1`` にする必要があります。"

#: ../../rst/dev_guide/testing_validate-modules.rst:97
msgid "invalid-module-schema"
msgstr "invalid-module-schema"

#: ../../rst/dev_guide/testing_validate-modules.rst:97
msgid "``AnsibleModule`` schema validation error"
msgstr "``AnsibleModule`` スキーマ検証エラー"

#: ../../rst/dev_guide/testing_validate-modules.rst:98
msgid "invalid-removal-version"
msgstr "invalid-removal-version"

#: ../../rst/dev_guide/testing_validate-modules.rst:98
msgid "The version at which a feature is supposed to be removed cannot be parsed (for collections, it must be a semantic version, see https://semver.org/)"
msgstr "機能が削除されることになっているバージョンは解析できません (コレクションの場合、セマンティックバージョンである必要があります。https://semver.org/ を参照してください)。"

#: ../../rst/dev_guide/testing_validate-modules.rst:99
msgid "invalid-requires-extension"
msgstr "invalid-requires-extension"

#: ../../rst/dev_guide/testing_validate-modules.rst:99
msgid "Module ``#AnsibleRequires -CSharpUtil`` should not end in .cs, Module ``#Requires`` should not end in .psm1"
msgstr "モジュール ``#AnsibleRequires -CSharpUtil`` の末尾を .cs にしないでください。モジュール ``#Requires`` の末尾を .psm1 にしないでください。"

#: ../../rst/dev_guide/testing_validate-modules.rst:100
msgid "missing-doc-fragment"
msgstr "missing-doc-fragment"

#: ../../rst/dev_guide/testing_validate-modules.rst:100
msgid "``DOCUMENTATION`` fragment missing"
msgstr "``DOCUMENTATION`` フラグメントがありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:101
msgid "missing-existing-doc-fragment"
msgstr "missing-existing-doc-fragment"

#: ../../rst/dev_guide/testing_validate-modules.rst:101
msgid "Pre-existing ``DOCUMENTATION`` fragment missing"
msgstr "既存の ``DOCUMENTATION`` フラグメントがありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:102
msgid "missing-documentation"
msgstr "missing-documentation"

#: ../../rst/dev_guide/testing_validate-modules.rst:102
msgid "No ``DOCUMENTATION`` provided"
msgstr "``DOCUMENTATION`` が提供されていません"

#: ../../rst/dev_guide/testing_validate-modules.rst:103
msgid "missing-examples"
msgstr "missing-examples"

#: ../../rst/dev_guide/testing_validate-modules.rst:103
msgid "No ``EXAMPLES`` provided"
msgstr "``EXAMPLES`` が提供されていません"

#: ../../rst/dev_guide/testing_validate-modules.rst:104
msgid "missing-gplv3-license"
msgstr "missing-gplv3-license"

#: ../../rst/dev_guide/testing_validate-modules.rst:104
msgid "GPLv3 license header not found"
msgstr "GPLv3 ライセンスヘッダーが見つかりませんでした"

#: ../../rst/dev_guide/testing_validate-modules.rst:105
msgid "missing-module-utils-basic-import"
msgstr "missing-module-utils-basic-import"

#: ../../rst/dev_guide/testing_validate-modules.rst:105
msgid "Did not find ``ansible.module_utils.basic`` import"
msgstr "``ansible.module_utils.basic`` インポートが見つかりませんでした"

#: ../../rst/dev_guide/testing_validate-modules.rst:106
msgid "missing-module-utils-import-csharp-requirements"
msgstr "missing-module-utils-import-csharp-requirements"

#: ../../rst/dev_guide/testing_validate-modules.rst:106
msgid "No ``Ansible.ModuleUtils`` or C# Ansible util requirements/imports found"
msgstr "``Ansible.ModuleUtils`` または C# Ansible ユーティリティーの 要件/インポートがあります"

#: ../../rst/dev_guide/testing_validate-modules.rst:107
msgid "missing-powershell-interpreter"
msgstr "missing-powershell-interpreter"

#: ../../rst/dev_guide/testing_validate-modules.rst:107
msgid "Interpreter line is not ``#!powershell``"
msgstr "インタープリター行は ``#!powershell`` ではありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:108
msgid "missing-python-interpreter"
msgstr "missing-python-interpreter"

#: ../../rst/dev_guide/testing_validate-modules.rst:108
msgid "Interpreter line is not ``#!/usr/bin/python``"
msgstr "インタープリター行は ``#!/usr/bin/python`` ではありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:109
msgid "missing-return"
msgstr "missing-return"

#: ../../rst/dev_guide/testing_validate-modules.rst:109
msgid "No ``RETURN`` documentation provided"
msgstr "``RETURN`` のドキュメントは提供されていません"

#: ../../rst/dev_guide/testing_validate-modules.rst:110
msgid "missing-return-legacy"
msgstr "missing-return-legacy"

#: ../../rst/dev_guide/testing_validate-modules.rst:110
msgid "No ``RETURN`` documentation provided for legacy module"
msgstr "レガシーモジュールには ``RETURN`` のドキュメントがありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:111
msgid "missing-suboption-docs"
msgstr "missing-suboption-docs"

#: ../../rst/dev_guide/testing_validate-modules.rst:111
msgid "Argument in argument_spec has sub-options but documentation does not define sub-options"
msgstr "argument_spec の引数にはサブオプションョンがありますが、ドキュメントではサブオプションが定義されていません"

#: ../../rst/dev_guide/testing_validate-modules.rst:112
msgid "module-incorrect-version-added"
msgstr "module-incorrect-version-added"

#: ../../rst/dev_guide/testing_validate-modules.rst:112
msgid "Module level ``version_added`` is incorrect"
msgstr "モジュールレベル ``version_added`` は正しくありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:113
msgid "module-invalid-version-added"
msgstr "module-invalid-version-added"

#: ../../rst/dev_guide/testing_validate-modules.rst:113
msgid "Module level ``version_added`` is not a valid version number"
msgstr "モジュールレベルの ``version_added`` は、有効なバージョン番号ではありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:114
msgid "module-utils-specific-import"
msgstr "module-utils-specific-import"

#: ../../rst/dev_guide/testing_validate-modules.rst:114
msgid "``module_utils`` imports should import specific components, not ``*``"
msgstr "``module_utils`` は、``*`` ではなく、特定のコンポーネントをインポートする必要があります"

#: ../../rst/dev_guide/testing_validate-modules.rst:115
msgid "multiple-utils-per-requires"
msgstr "multiple-utils-per-requires"

#: ../../rst/dev_guide/testing_validate-modules.rst:115
msgid "``Ansible.ModuleUtils`` requirements do not support multiple modules per statement"
msgstr "``Ansible.ModuleUtils`` 要件は、ステートメントごとに複数のモジュールをサポートしません。"

#: ../../rst/dev_guide/testing_validate-modules.rst:116
msgid "multiple-csharp-utils-per-requires"
msgstr "multiple-csharp-utils-per-requires"

#: ../../rst/dev_guide/testing_validate-modules.rst:116
msgid "Ansible C# util requirements do not support multiple utils per statement"
msgstr "C# ユーティリティー要件は、ステートメントごとに複数のモジュールをサポートしません。"

#: ../../rst/dev_guide/testing_validate-modules.rst:117
msgid "no-default-for-required-parameter"
msgstr "no-default-for-required-parameter"

#: ../../rst/dev_guide/testing_validate-modules.rst:117
msgid "Option is marked as required but specifies a default. Arguments with a default should not be marked as required"
msgstr "オプションは必須と識別されますが、デフォルトの引数を指定します。デフォルトの引数は必須と識別しないでください。"

#: ../../rst/dev_guide/testing_validate-modules.rst:118
msgid "no-log-needed"
msgstr "no-log-needed"

#: ../../rst/dev_guide/testing_validate-modules.rst:118
#: ../../rst/dev_guide/testing_validate-modules.rst:126
#: ../../rst/dev_guide/testing_validate-modules.rst:127
#: ../../rst/dev_guide/testing_validate-modules.rst:129
#: ../../rst/dev_guide/testing_validate-modules.rst:130
msgid "Parameters"
msgstr "パラメーター"

#: ../../rst/dev_guide/testing_validate-modules.rst:118
msgid "Option name suggests that the option contains a secret value, while ``no_log`` is not specified for this option in the argument spec. If this is a false positive, explicitly set ``no_log=False``"
msgstr "オプション名は、オプションにシークレット値が含まれていることを示唆していますが、引数仕様ではこのオプションに対して ``no_log`` が指定されていません。このオプションが誤検出の場合は明示的に ``no_log=False`` に設定します。"

#: ../../rst/dev_guide/testing_validate-modules.rst:119
msgid "nonexistent-parameter-documented"
msgstr "nonexistent-parameter-documented"

#: ../../rst/dev_guide/testing_validate-modules.rst:119
msgid "Argument is listed in DOCUMENTATION.options, but not accepted by the module"
msgstr "引数は DOCUMENTATION.options に一覧表示されますが、モジュールでは受け入れられません。"

#: ../../rst/dev_guide/testing_validate-modules.rst:120
msgid "option-incorrect-version-added"
msgstr "option-incorrect-version-added"

#: ../../rst/dev_guide/testing_validate-modules.rst:120
msgid "``version_added`` for new option is incorrect"
msgstr "新しいオプションの ``version_added`` は正しくありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:121
msgid "option-invalid-version-added"
msgstr "option-invalid-version-added"

#: ../../rst/dev_guide/testing_validate-modules.rst:121
msgid "``version_added`` for option is not a valid version number"
msgstr "``version_added`` オプションが有効なバージョン番号ではありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:122
msgid "parameter-invalid"
msgstr "parameter-invalid"

#: ../../rst/dev_guide/testing_validate-modules.rst:122
msgid "Argument in argument_spec is not a valid python identifier"
msgstr "argument_spec の引数は有効な python 識別子ではありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:123
msgid "parameter-invalid-elements"
msgstr "parameter-invalid-elements"

#: ../../rst/dev_guide/testing_validate-modules.rst:123
msgid "Value for \"elements\" is valid only when value of \"type\" is ``list``"
msgstr "「elements」の値は、「type」の値が ``list`` である場合に限り有効です"

#: ../../rst/dev_guide/testing_validate-modules.rst:124
msgid "implied-parameter-type-mismatch"
msgstr "implied-parameter-type-mismatch"

#: ../../rst/dev_guide/testing_validate-modules.rst:124
msgid "Argument_spec implies ``type=\"str\"`` but documentation defines it as different data type"
msgstr "argument_spec には ``type=\"str\"`` の意が含まれますが、ドキュメントでは、別のデータ型として指定されています"

#: ../../rst/dev_guide/testing_validate-modules.rst:125
msgid "parameter-type-not-in-doc"
msgstr "parameter-type-not-in-doc"

#: ../../rst/dev_guide/testing_validate-modules.rst:125
msgid "Type value is defined in ``argument_spec`` but documentation doesn't specify a type"
msgstr "タイプ値は ``argument_spec`` で定義されていますが、ドキュメントはタイプを指定していません"

#: ../../rst/dev_guide/testing_validate-modules.rst:126
msgid "parameter-alias-repeated"
msgstr "parameter-alias-repeated"

#: ../../rst/dev_guide/testing_validate-modules.rst:126
msgid "argument in argument_spec has at least one alias specified multiple times in aliases"
msgstr "argument_spec の引数には、エイリアスに複数回指定されたエイリアスが 1 つ以上含まれます"

#: ../../rst/dev_guide/testing_validate-modules.rst:127
msgid "parameter-alias-self"
msgstr "parameter-alias-self"

#: ../../rst/dev_guide/testing_validate-modules.rst:127
msgid "argument in argument_spec is specified as its own alias"
msgstr "argument_spec の引数は、独自のエイリアスとして指定されます"

#: ../../rst/dev_guide/testing_validate-modules.rst:128
msgid "parameter-documented-multiple-times"
msgstr "parameter-documented-multiple-times"

#: ../../rst/dev_guide/testing_validate-modules.rst:128
msgid "argument in argument_spec with aliases is documented multiple times"
msgstr "エイリアスを持つ argument_spec の引数が複数回文書化されています"

#: ../../rst/dev_guide/testing_validate-modules.rst:129
msgid "parameter-list-no-elements"
msgstr "parameter-list-no-elements"

#: ../../rst/dev_guide/testing_validate-modules.rst:129
msgid "argument in argument_spec \"type\" is specified as ``list`` without defining \"elements\""
msgstr "argument_spec「type」の引数は、「要素」を定義せずに ``list`` のように指定されます。"

#: ../../rst/dev_guide/testing_validate-modules.rst:130
msgid "parameter-state-invalid-choice"
msgstr "parameter-state-invalid-choice"

#: ../../rst/dev_guide/testing_validate-modules.rst:130
msgid "Argument ``state`` includes ``get``, ``list`` or ``info`` as a choice.  Functionality should be in an ``_info`` or (if further conditions apply) ``_facts`` module."
msgstr "引数 ``state`` には、``get``、``list``、または ``info`` が含まれています。機能性は ``_info`` または (追加の条件が適用される場合は) ``_facts`` モジュールである必要があります。"

#: ../../rst/dev_guide/testing_validate-modules.rst:131
msgid "python-syntax-error"
msgstr "python-syntax-error"

#: ../../rst/dev_guide/testing_validate-modules.rst:131
msgid "Python ``SyntaxError`` while parsing module"
msgstr "モジュールの解析中の Python ``SyntaxError``"

#: ../../rst/dev_guide/testing_validate-modules.rst:132
msgid "removal-version-must-be-major"
msgstr "removal-version-must-be-major"

#: ../../rst/dev_guide/testing_validate-modules.rst:132
msgid "According to the semantic versioning specification (https://semver.org/), the only versions in which features are allowed to be removed are major versions (x.0.0)"
msgstr "セマンティックバージョニング仕様 (https://semver.org/) によると、機能の削除が許可されているバージョンはメジャーバージョン (x.0.0) のみです。"

#: ../../rst/dev_guide/testing_validate-modules.rst:133
msgid "return-syntax-error"
msgstr "return-syntax-error"

#: ../../rst/dev_guide/testing_validate-modules.rst:133
msgid "``RETURN`` is not valid YAML, ``RETURN`` fragments missing  or invalid"
msgstr "``RETURN`` は、有効な YAML ではありません。``RETURN`` フラグメントが見つからないか、無効です。"

#: ../../rst/dev_guide/testing_validate-modules.rst:134
msgid "return-invalid-version-added"
msgstr "return-invalid-version-added"

#: ../../rst/dev_guide/testing_validate-modules.rst:134
msgid "``version_added`` for return value is not a valid version number"
msgstr "戻り値の ``version_added`` は、有効なバージョン番号ではありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:135
msgid "subdirectory-missing-init"
msgstr "subdirectory-missing-init"

#: ../../rst/dev_guide/testing_validate-modules.rst:135
msgid "Ansible module subdirectories must contain an ``__init__.py``"
msgstr "Ansible モジュールのサブディレクトリーには ``__init__.py`` が含まれている必要があります。"

#: ../../rst/dev_guide/testing_validate-modules.rst:136
msgid "try-except-missing-has"
msgstr "try-except-missing-has"

#: ../../rst/dev_guide/testing_validate-modules.rst:136
msgid "Try/Except ``HAS_`` expression missing"
msgstr "try/Except ``HAS_`` 式がない"

#: ../../rst/dev_guide/testing_validate-modules.rst:137
msgid "undocumented-parameter"
msgstr "undocumented-parameter"

#: ../../rst/dev_guide/testing_validate-modules.rst:137
msgid "Argument is listed in the argument_spec, but not documented in the module"
msgstr "引数が argument_spec に記載されていますが、このモジュールでは文書化されていません。"

#: ../../rst/dev_guide/testing_validate-modules.rst:138
msgid "unidiomatic-typecheck"
msgstr "unidiomatic-typecheck"

#: ../../rst/dev_guide/testing_validate-modules.rst:138
msgid "Type comparison using ``type()`` found. Use ``isinstance()`` instead"
msgstr "``type()`` を使用したタイプ比較。代わりに ``isinstance()`` を使用してください。"

#: ../../rst/dev_guide/testing_validate-modules.rst:139
msgid "unknown-doc-fragment"
msgstr "unknown-doc-fragment"

#: ../../rst/dev_guide/testing_validate-modules.rst:139
msgid "Unknown pre-existing ``DOCUMENTATION`` error"
msgstr "不明な既存の ``DOCUMENTATION`` エラー"

#: ../../rst/dev_guide/testing_validate-modules.rst:140
msgid "use-boto3"
msgstr "use-boto3"

#: ../../rst/dev_guide/testing_validate-modules.rst:140
msgid "``boto`` import found, new modules should use ``boto3``"
msgstr "``boto`` インポートが見つかりました。代わりに ``boto3`` を使用してください"

#: ../../rst/dev_guide/testing_validate-modules.rst:141
msgid "use-fail-json-not-sys-exit"
msgstr "use-fail-json-not-sys-exit"

#: ../../rst/dev_guide/testing_validate-modules.rst:141
msgid "``sys.exit()`` call found. Should be ``exit_json``/``fail_json``"
msgstr "``sys.exit()`` 呼び出しが見つかりました。``exit_json``/``fail_json`` でなければなりません。"

#: ../../rst/dev_guide/testing_validate-modules.rst:142
msgid "use-module-utils-urls"
msgstr "use-module-utils-urls"

#: ../../rst/dev_guide/testing_validate-modules.rst:142
msgid "``requests`` import found, should use ``ansible.module_utils.urls`` instead"
msgstr "``requests`` インポートしています。代わりに ``ansible.module_utils.urls`` を使用してください"

#: ../../rst/dev_guide/testing_validate-modules.rst:143
msgid "use-run-command-not-os-call"
msgstr "use-run-command-not-os-call"

#: ../../rst/dev_guide/testing_validate-modules.rst:143
msgid "``os.call`` used instead of ``module.run_command``"
msgstr "``module.run_command`` の代わりに、``os.call`` を使用します。"

#: ../../rst/dev_guide/testing_validate-modules.rst:144
msgid "use-run-command-not-popen"
msgstr "use-run-command-not-popen"

#: ../../rst/dev_guide/testing_validate-modules.rst:144
msgid "``subprocess.Popen`` used instead of ``module.run_command``"
msgstr "``module.run_command`` の代わりに、``subprocess.Popen`` を使用します。"

#: ../../rst/dev_guide/testing_validate-modules.rst:145
msgid "use-short-gplv3-license"
msgstr "use-short-gplv3-license"

#: ../../rst/dev_guide/testing_validate-modules.rst:145
msgid "GPLv3 license header should be the :ref:`short form <copyright>` for new modules"
msgstr "GPLv3 ライセンスヘッダーは、新しいモジュールの :ref:`短縮形 <copyright>` である必要があります"

#: ../../rst/dev_guide/testing_validate-modules.rst:146
msgid "mutually_exclusive-type"
msgstr "mutually_exclusive-type"

#: ../../rst/dev_guide/testing_validate-modules.rst:146
msgid "mutually_exclusive entry contains non-string value"
msgstr "mutually_exclusive エントリーには文字列以外の値が含まれます"

#: ../../rst/dev_guide/testing_validate-modules.rst:147
msgid "mutually_exclusive-collision"
msgstr "mutually_exclusive-collision"

#: ../../rst/dev_guide/testing_validate-modules.rst:147
msgid "mutually_exclusive entry has repeated terms"
msgstr "mutually_exclusive エントリーが繰り返し使用されます"

#: ../../rst/dev_guide/testing_validate-modules.rst:148
msgid "mutually_exclusive-unknown"
msgstr "mutually_exclusive-unknown"

#: ../../rst/dev_guide/testing_validate-modules.rst:148
msgid "mutually_exclusive entry contains option which does not appear in argument_spec (potentially an alias of an option?)"
msgstr "mutually_exclusive エントリーには、argument_spec に表示されないオプションが含まれています (オプションのエイリアスである可能性がありますか?)"

#: ../../rst/dev_guide/testing_validate-modules.rst:149
msgid "required_one_of-type"
msgstr "required_one_of-type"

#: ../../rst/dev_guide/testing_validate-modules.rst:149
msgid "required_one_of entry contains non-string value"
msgstr "required_one_of エントリーには文字列以外の値が含まれます"

#: ../../rst/dev_guide/testing_validate-modules.rst:150
msgid "required_one_of-collision"
msgstr "required_one_of-collision"

#: ../../rst/dev_guide/testing_validate-modules.rst:150
msgid "required_one_of entry has repeated terms"
msgstr "required_one_of エントリーが繰り返し使用されます"

#: ../../rst/dev_guide/testing_validate-modules.rst:151
msgid "required_one_of-unknown"
msgstr "required_one_of-unknown"

#: ../../rst/dev_guide/testing_validate-modules.rst:151
msgid "required_one_of entry contains option which does not appear in argument_spec (potentially an alias of an option?)"
msgstr "required_one_of エントリーには、argument_spec に表示されないオプションが含まれています (オプションのエイリアスである可能性がありますか?)"

#: ../../rst/dev_guide/testing_validate-modules.rst:152
msgid "required_together-type"
msgstr "required_together-type"

#: ../../rst/dev_guide/testing_validate-modules.rst:152
msgid "required_together entry contains non-string value"
msgstr "required_together エントリーには文字列以外の値が含まれます"

#: ../../rst/dev_guide/testing_validate-modules.rst:153
msgid "required_together-collision"
msgstr "required_together-collision"

#: ../../rst/dev_guide/testing_validate-modules.rst:153
msgid "required_together entry has repeated terms"
msgstr "required_together エントリーが繰り返し使用されます"

#: ../../rst/dev_guide/testing_validate-modules.rst:154
msgid "required_together-unknown"
msgstr "required_together-unknown"

#: ../../rst/dev_guide/testing_validate-modules.rst:154
msgid "required_together entry contains option which does not appear in argument_spec (potentially an alias of an option?)"
msgstr "required_together エントリーには、argument_spec に表示されないオプションが含まれています (オプションのエイリアスである可能性がありますか?)"

#: ../../rst/dev_guide/testing_validate-modules.rst:155
msgid "required_if-is_one_of-type"
msgstr "required_if-is_one_of-type"

#: ../../rst/dev_guide/testing_validate-modules.rst:155
msgid "required_if entry has a fourth value which is not a bool"
msgstr "required_if エントリーには bool ではない 4 つ目の値がある"

#: ../../rst/dev_guide/testing_validate-modules.rst:156
msgid "required_if-requirements-type"
msgstr "required_if-requirements-type"

#: ../../rst/dev_guide/testing_validate-modules.rst:156
msgid "required_if entry has a third value (requirements) which is not a list or tuple"
msgstr "required_if エントリーには、リストまたはタプルではない 3 つの値 (必須) があります。"

#: ../../rst/dev_guide/testing_validate-modules.rst:157
msgid "required_if-requirements-collision"
msgstr "required_if-requirements-collision"

#: ../../rst/dev_guide/testing_validate-modules.rst:157
msgid "required_if entry has repeated terms in requirements"
msgstr "required_if エントリーが繰り返し使用されます"

#: ../../rst/dev_guide/testing_validate-modules.rst:158
msgid "required_if-requirements-unknown"
msgstr "required_if-requirements-unknown"

#: ../../rst/dev_guide/testing_validate-modules.rst:158
msgid "required_if entry's requirements contains option which does not appear in argument_spec (potentially an alias of an option?)"
msgstr "required_if エントリーの要件には、argument_spec に表示されないオプションが含まれています (オプションのエイリアスである可能性がありますか?)"

#: ../../rst/dev_guide/testing_validate-modules.rst:159
msgid "required_if-unknown-key"
msgstr "required_if-unknown-key"

#: ../../rst/dev_guide/testing_validate-modules.rst:159
msgid "required_if entry's key does not appear in argument_spec (potentially an alias of an option?)"
msgstr "required_if エントリーのキーが argument_spec に表示されません (オプションのエイリアスである可能性がありますか?)"

#: ../../rst/dev_guide/testing_validate-modules.rst:160
msgid "required_if-key-in-requirements"
msgstr "required_if-key-in-requirements"

#: ../../rst/dev_guide/testing_validate-modules.rst:160
msgid "required_if entry contains its key in requirements list/tuple"
msgstr "required_if エントリーには要件リスト/タプルのキーが含まれます"

#: ../../rst/dev_guide/testing_validate-modules.rst:161
msgid "required_if-value-type"
msgstr "required_if-value-type"

#: ../../rst/dev_guide/testing_validate-modules.rst:161
msgid "required_if entry's value is not of the type specified for its key"
msgstr "required_if エントリーの値は、キーに指定されたタイプではありません"

#: ../../rst/dev_guide/testing_validate-modules.rst:162
msgid "required_by-collision"
msgstr "required_by-collision"

#: ../../rst/dev_guide/testing_validate-modules.rst:162
msgid "required_by entry has repeated terms"
msgstr "required_by エントリーが繰り返し使用されます"

#: ../../rst/dev_guide/testing_validate-modules.rst:163
msgid "required_by-unknown"
msgstr "required_by-unknown"

#: ../../rst/dev_guide/testing_validate-modules.rst:163
msgid "required_by entry contains option which does not appear in argument_spec (potentially an alias of an option?)"
msgstr "required_by エントリーには、argument_spec に表示されないオプションが含まれます (オプションのエイリアスである可能性がありますか?)"

#: ../../rst/dev_guide/testing_validate-modules.rst:164
msgid "version-added-must-be-major-or-minor"
msgstr "version-added-must-be-major-or-minor"

#: ../../rst/dev_guide/testing_validate-modules.rst:164
msgid "According to the semantic versioning specification (https://semver.org/), the only versions in which features are allowed to be added are major and minor versions (x.y.0)"
msgstr "セマンティックバージョニング仕様 (https://semver.org/) によると、機能の追加が許可されているバージョンはメジャーバージョンおよびマイナーバージョン (x.y.0) のみです"

#~ msgid "All Python imports in ``lib/ansible/modules/`` and ``lib/ansible/module_utils/`` which are not from the Python standard library must be imported in a try/except ImportError block."
#~ msgstr ""

#~ msgid "`irc.freenode.net <http://irc.freenode.net>`_"
#~ msgstr "`irc.freenode.net <http://irc.freenode.net>`_"

#~ msgid "Collections are a distribution format for Ansible content. You can use collections to package and distribute playbooks, roles, modules, and plugins. You can publish and use collections through `Ansible Galaxy <https://galaxy.ansible.com>`_."
#~ msgstr "コレクションは、Ansible コンテンツのディストリビューション形式です。コレクションを使用して、Playbook、ロール、モジュール、プラグインをパッケージ化および配布できます。`Ansible Galaxy <https://galaxy.ansible.com>`_ を介してコレクションを公開および使用できます。"

#~ msgid "For details on how to *use* collections see :ref:`collections`."
#~ msgstr "*use* コレクションの使用方法は、「:ref:`collections`」を参照してください。"

#~ msgid "For the current development status of Collections and FAQ see `Ansible Collections Overview and FAQ <https://github.com/ansible-collections/overview/blob/main/README.rst>`_."
#~ msgstr "コレクションおよび FAQ の現在の開発ステータスは、「`Ansible Collections Overview and FAQ <https://github.com/ansible-collections/overview/blob/main/README.rst>`_」を参照してください。"

#~ msgid "Put general documentation for the collection here. Keep the specific documentation for plugins and modules embedded as Python docstrings. Use the ``docs`` folder to describe how to use the roles and plugins the collection provides, role requirements, and so on. Use markdown and do not add subfolders."
#~ msgstr "ここでコレクションに関する一般的なドキュメントを追加します。Python ドキュメント文字列として埋め込まれたプラグインおよびモジュールに関する特定のドキュメントを保持します。``docs`` フォルダーを使用して、ロール、コレクションが提供するロール、ロール要件などを説明します。マークダウンを使用し、サブフォルダーを追加しないでください。"

#~ msgid "TBD."
#~ msgstr "現在準備中です。"

#~ msgid "To start a new collection:"
#~ msgstr "新規コレクションを開始するには、以下を使用します。"

#~ msgid "Create a collection skeleton with the ``collection init`` command. See :ref:`creating_collections_skeleton` above."
#~ msgstr "``collection init`` コマンドでコレクションスケルトンを作成します。上記の「:ref:`creating_collections_skeleton`」を参照してください。"

#~ msgid "Certain files and folders are excluded when building the collection artifact. See :ref:`ignoring_files_and_folders_collections`  to exclude other files you would not want to distribute."
#~ msgstr "コレクションアーティファクトのビルド時に、特定のファイルおよびフォルダーは除外されます。配布したくない他のファイルを除外するには、「:ref:`ignoring_files_and_folders_collections`」を参照してください。"

#~ msgid "If you used the now-deprecated ``Mazer`` tool for any of your collections, delete any and all files it added to your :file:`releases/` directory before you build your collection with ``ansible-galaxy``."
#~ msgstr "今回の非推奨となった ``Mazer`` ツールをコレクションに使用した場合は、``ansible-galaxy`` でコレクションをビルドする前に、:file:`releases/` ディレクトリーに追加したすべてのファイルを削除します。"

#~ msgid "This tarball is mainly intended to upload to Galaxy as a distribution method, but you can use it directly to install the collection on target systems."
#~ msgstr "この tarball は、配布方法として主に Galaxy にアップロードすることを目的としていますが、ターゲットシステムにコレクションをインストールするために直接使用することもできます。"

#~ msgid "You can try your collection locally by installing it from the tarball. The following will enable an adjacent playbook to access the collection:"
#~ msgstr "コレクションを tarball からインストールすることで、コレクションをローカルで試すことができます。以下では、隣接用の Playbook がコレクションにアクセスできるようになります。"

#~ msgid "You should use one of the values configured in :ref:`COLLECTIONS_PATHS` for your path. This is also where Ansible itself will expect to find collections when attempting to use them. If you don't specify a path value, ``ansible-galaxy collection install`` installs the collection in the first path defined in :ref:`COLLECTIONS_PATHS`, which by default is ``~/.ansible/collections``."
#~ msgstr "パスのために、:ref:`COLLECTIONS_PATHS` で構成された値の 1 つを使用する必要があります。これは、Ansible 自体がコレクションを使用しようとしたときにコレクションを見つけることを期待する場所でもあります。パス値を指定しない場合は、:ref:`COLLECTIONS_PATHS` で定義された最初のパスにコレクションをインストールします。これは、デフォルトは、``~/.ansible/collections`` となります。"

#~ msgid "If you want to use a collection directly out of a checked out git repository, see :ref:`hacking_collections`."
#~ msgstr "確認された git リポジトリーから直接コレクションを使用する場合は、「:ref:`hacking_collections`」を参照してください。"

#~ msgid "Next, try using the local collection inside a playbook. For examples and more details see :ref:`Using collections <using_collections>`"
#~ msgstr "次に、Playbook 内でローカルコレクションの使用を試行します。例および詳細は、「:ref:`コレクションの使用 <using_collections>`」を参照してください。"

#~ msgid "You can also test a version of your collection in development by installing it from a git repository."
#~ msgstr "また、Git リポジトリーからインストールすることで、開発でコレクションのバージョンをテストすることもできます。"

#~ 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`` ファイルへのパスではなく) コレクションまたは複数のコレクションへのディレクトリーである必要があります。"

#~ msgid "You can publish collections to Galaxy using the ``ansible-galaxy collection publish`` command or the Galaxy UI itself. You need a namespace on Galaxy to upload your collection. See `Galaxy namespaces <https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespaces>`_ on the Galaxy docsite for details."
#~ msgstr "``ansible-galaxy collection publish`` コマンドまたは Galaxy UI 自体を使用して、コレクションを Galaxy に公開することができます。コレクションをアップロードするには、Galaxy に名前空間が必要です。詳細は、Galaxy のドキュメントスイートの「`Galaxy 名前空間 <https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespaces>`_」を参照してください。"

#~ msgid "Once you upload a version of a collection, you cannot delete or modify that version. Ensure that everything looks okay before you upload it."
#~ msgstr "コレクションのバージョンをアップロードしたら、そのバージョンを削除または変更することはできません。アップロードする前に、すべての情報が適切であることを確認します。"

#~ msgid "To upload your collection to Galaxy, you must first obtain an API token (``--token`` in the ``ansible-galaxy`` CLI command or ``token`` in the :file:`ansible.cfg` file under the ``galaxy_server`` section). The API token is a secret token used to protect your content."
#~ msgstr "コレクションを Galaxy にアップロードするには、まず API トークンを取得する必要があります (``ansible-galaxy`` CLI コマンドの ``--token``、または ``galaxy_server`` セクションの下の :file:`ansible.cfg` ファイルの ``token``) は、コンテンツを保護するために使用されるシークレットトークン。"

#~ msgid "Storing or using your API token"
#~ msgstr "API トークンの保存または使用"

#~ msgid "Once you have retrieved your API token, you can store or use the token for collections in two ways:"
#~ msgstr "API トークンを取得したら、2 つの方法でコレクションにトークンを保存または使用することができます。"

#~ msgid "Pass the token to  the ``ansible-galaxy`` command using the ``--token``."
#~ msgstr "``--token`` を使用して、トークンを ``ansible-galaxy`` コマンドに渡します。"

#~ msgid "Specify the token within a Galaxy server list in your :file:`ansible.cfg` file."
#~ msgstr ":file:`ansible.cfg` ファイルの Galaxy サーバーリスト内のトークンを指定します。"

#~ msgid "Using the ``token`` argument"
#~ msgstr "``token`` 引数の使用"

#~ msgid "You can use the ``--token`` argument with the ``ansible-galaxy`` command (in conjunction with the ``--server`` argument or :ref:`GALAXY_SERVER` setting in your :file:`ansible.cfg` file). You cannot use ``apt-key`` with any servers defined in your :ref:`Galaxy server list <galaxy_server_config>`."
#~ msgstr "``--token`` 引数は、``ansible-galaxy`` コマンド (:file:`ansible.cfg` ファイルの ``--server`` 引数または :ref:`GALAXY_SERVER` 設定とともに) で使用できます。:ref:`Galaxy サーバー一覧 <galaxy_server_config>` で定義されているサーバーでは、``apt-key`` を使用することはできません。"

#~ msgid "Specify the token within a Galaxy server list"
#~ msgstr "Galaxy サーバー一覧内でトークンの指定"

#~ msgid "With this option, you configure one or more servers for Galaxy in your :file:`ansible.cfg` file under the ``galaxy_server_list`` section. For each server, you also configure the token."
#~ msgstr "このオプションを使用して、``galaxy_server_list`` セクションの下にある :file:`ansible.cfg` で Galaxy 用に 1 つ以上のサーバーを構成します。サーバーごとに、トークンも構成します。"

#~ msgid "See :ref:`galaxy_server_config` for complete details."
#~ msgstr "詳細は、「:ref:`galaxy_server_config`」を参照してください。"

#~ 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`). If you are only publishing your collection to Ansible Galaxy, you do not need any further configuration. If you are using Red Hat Automation Hub or any other Galaxy server, see :ref:`Configuring the ansible-galaxy client <galaxy_server_config>`."
#~ msgstr "デフォルトでは、``ansible-galaxy`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の下の :file:`ansible.cfg` ファイルに記載されるように)。`galaxy_server` コレクションのみを Ansible Galaxy に公開している場合は、追加設定は必要ありません。Red Hat Automation Hub またはその他の Galaxy サーバーを使用している場合は、「:ref:`ansible-galaxy クライアントの設定 <galaxy_server_config>`」を参照してください。"

#~ msgid "When uploading collections it doesn't matter which namespace you select. The collection will be uploaded to the namespace specified in the collection metadata in the ``galaxy.yml`` file. If you're not an owner of the namespace, the upload request will fail."
#~ msgstr "コレクションをアップロードする際に、選択した名前空間は重要ではありません。コレクションは ``galaxy.yml`` ファイルのコレクションメタデータに指定された名前空間にアップロードされます。名前空間の所有者がない場合、アップロード要求は失敗します。"

#~ msgid "Once Galaxy uploads and accepts a collection, you will be redirected to the **My Imports** page, which displays output from the import process, including any errors or warnings about the metadata and content contained in the collection."
#~ msgstr "Galaxy がコレクションをアップロードして受け入れると、**My Imports** ページにリダイレクトされます。このページには、コレクションに含まれるメタデータやコンテンツに関するエラーや警告など、インポート処理の出力が表示されます。"

#~ msgid "Collection versions"
#~ msgstr "コレクションのバージョン"

#~ msgid "Once you upload a version of a collection, you cannot delete or modify that version. Ensure that everything looks okay before uploading. The only way to change a collection is to release a new version. The latest version of a collection (by highest version number) will be the version displayed everywhere in Galaxy; however, users will still be able to download older versions."
#~ msgstr "コレクションのバージョンをアップロードしたら、そのバージョンを削除または変更することはできません。アップロードする前に、すべてが正常に見えることを確認してください。コレクションを変更する唯一の方法は、新しいバージョンをリリースすることです。(最大バージョン番号による) コレクションの最新バージョンは、Galaxy のあらゆる場所に表示されるバージョンになります。ただし、ユーザーは引き続き古いバージョンをダウンロードできます。"

#~ msgid "BOTMETA.yml"
#~ msgstr "BOTMETA.yml"

#~ msgid "We assume that you have included ``~/dev/ansible/collections/`` in :ref:`COLLECTIONS_PATHS`, and if that path mentions multiple directories, that you made sure that no other directory earlier in the search path contains a copy of ``community.general``. Create the directory ``~/dev/ansible/collections/ansible_collections/community``, and in it clone `the community.general Git repository <https://github.com/ansible-collections/community.general/>`_ or a fork of it into the folder ``general``::"
#~ msgstr ":ref:`COLLECTIONS_PATHS` に ``~/dev/ansible/collections/`` が含まれており、そのパスで複数のディレクトリーに言及されている場合は、検索パスの他のディレクトリーに ``community.general`` のコピーが含まれないようにします。``~/dev/ansible/collections/ansible_collections/community`` ディレクトリーを作成して、その中に `the community.general Git repository <https://github.com/ansible-collections/community.general/>`_ のクローンを作成するか、フォルダー ``general`` にそのディレクトリーのフォークを作成します。"

#~ msgid "For collections hosted in the ``ansible_collections`` GitHub org, create a branch and commit your changes on the branch. When you are done (remember to add tests, see :ref:`testing_collections`), push your changes to your fork of the collection and create a Pull Request. For other collections, especially for collections not hosted on GitHub, check the ``README.md`` of the collection for information on contributing to it."
#~ msgstr "``ansible_collections`` GitHub の団体でホストされるコレクションの場合は、ブランチを作成し、ブランチで変更をコミットします。これが完了したら、(テストを追加する方法は、:ref:`testing_collections` を参照してください)。コレクションのフォークに変更をプッシュし、プル要求を作成します。他のコレクション (特に GitHub がホストされていないコレクション) については、コレクションの ``README.md`` でこれに貢献する情報を確認してください。"

#~ msgid "We recommend that you use the `antsibull-changelog <https://github.com/ansible-community/antsibull-changelog>`_ tool to generate Ansible-compatible changelogs for your collection. The Ansible changelog uses the output of this tool to collate all the collections included in an Ansible release into one combined changelog for the release."
#~ msgstr "`antsibull-changelog <https://github.com/ansible-community/antsibull-changelog>`_ ツールを使用してコレクションに Ansible 互換の changelog を生成することが推奨されます。Ansibleの changelog は、このツールの出力を利用して、Ansible のリリースに含まれるすべてのコレクションを、そのリリースの 1 つの統合されたチェンジログに照合します。"

#~ msgid "Porting Guide entries"
#~ msgstr "移植ガイドエントリー"

#~ msgid "The following changelog fragment categories are consumed by the Ansible changelog generator into the Ansible Porting Guide:"
#~ msgstr "以下の changelog フラグメントカテゴリーは、Ansible changelog ジェネレーターが Ansible 移植ガイドに使用されます。"

#~ msgid "Understand the collections metadata structure."
#~ msgstr "コレクションのメタデータ構造を理解します。"

#~ msgid "When the script is called with the single argument ``--list``, the script must output to stdout a JSON-encoded hash or dictionary that contains all the groups to be managed. Each group's value should be either a hash or dictionary containing a list of each host, any child groups, and potential group variables, or simply a list of hosts::"
#~ msgstr "スクリプトが単一の引数 ``--list`` で呼び出されると、スクリプトは、標準出力に、管理するすべてのグループが含まれる JSON でエンコードされたハッシュまたはディクショナリーを出力する必要があります。各グループの値は、各ホスト、子グループ、および潜在的なグループ変数の一覧を含むハッシュまたはディクショナリーにする必要があります。"

#~ msgid "When called with the argument ``--host <hostname>`` (where <hostname> is a host from above), the script must print either an empty JSON hash/dictionary, or a hash/dictionary of variables to make them available to templates and playbooks. For example::"
#~ msgstr "引数 ``--host <hostname>`` (<hostname> は上述のホスト) で呼び出されると、スクリプトは空の JSON ハッシュ/ディクショナリーか、テンプレートや Playbook で利用できるようにするための変数のハッシュ/ディクショナリーを出力しなければなりません。たとえば、以下のようになります。"

#~ msgid "`Ansible Tower <https://www.ansible.com/products/tower>`_"
#~ msgstr "`Ansible Tower <https://www.ansible.com/products/tower>`_"

#~ msgid "The easiest, quickest, and the most popular way to extend Ansible is to use a local module or a plugin. You can create them or copy existing ones for local use. You can store a local module or plugin on your Ansible control node and share it with your team or organization. You can also share a local plugin or module by including it in a collection or embedding it in a role, then publishing the collection or role on Ansible Galaxy. If you are using roles on Ansible Galaxy, then you are already using local modules and plugins without realizing it."
#~ msgstr "Ansible を拡張する最も簡単な方法は、ローカルモジュールまたはプラグインを使用することです。ローカルで使用するためにこれらを作成するか、既存のものをコピーすることができます。Ansible コントロールノードにローカルモジュールまたはプラグインを保存し、チームまたは組織と共有することができます。また、ローカルプラグインまたはモジュールをコレクションに含めるか、ロールに埋め込むことで、Ansible Galaxy にコレクションまたはロールを公開することもできます。Ansible Galaxy でロールを使用している場合は、認識せずにローカルモジュールとプラグインをすでに使用していることになります。"

#~ msgid "If you are using an existing module or plugin but Ansible can't find it, this page is all you need. However, if you want to create a plugin or a module, go to :ref:`developing_plugins` and :ref:`developing_modules_general` topics and then return to this page to know how to add it locally."
#~ msgstr "既存のモジュールまたはプラグインを使用しているにもかかわらず、Ansible で見つからない場合、このページのみが必要となります。プラグインまたはモジュールを作成する場合は、:ref:`developing_plugins` および :ref:`developing_modules_general` トピックに移動してから、このページに戻り、ローカルで追加する方法を説明します。"

#~ msgid "To save a local module or plugin such that Ansible can find and use it, add the module or plugin in the appropriate directory (the directories are specified in later parts of this topic)."
#~ msgstr "Ansible が検出して使用するようにローカルモジュールまたはプラグインを保存するには、適切なディレクトリーにモジュールまたはプラグインを追加します (ディレクトリーは、本トピックの後半で指定されています)。"

#~ msgid "Adding a module locally"
#~ msgstr "モジュールをローカルで追加"

#~ msgid "Ansible automatically loads all executable files found in certain directories as modules."
#~ msgstr "Ansible は、特定のディレクトリーにある実行可能ファイルをすべてモジュールとして自動的に読み込みます。"

#~ msgid "For local modules, use the name of the file as the module name: for example, if the module file is ``~/.ansible/plugins/modules/local_users.py``, use ``local_users`` as the module name."
#~ msgstr "ローカルモジュールの場合は、ファイル名をモジュール名として使用します。たとえば、モジュールファイルが ``~/.ansible/plugins/modules/local_users.py`` の場合は、モジュール名として ``local_users`` を使用します。"

#~ msgid "To load your local modules automatically and make them available to all playbooks and roles, add them in any of these locations:"
#~ msgstr "ローカルモジュールを自動的に読み込み、すべての Playbook およびロールで使用できるようにするには、それらを以下のいずれかの場所に追加します。"

#~ msgid "any directory added to the ``ANSIBLE_LIBRARY`` environment variable (``$ANSIBLE_LIBRARY`` takes a colon-separated list like ``$PATH``)"
#~ msgstr "``ANSIBLE_LIBRARY`` 環境変数に追加されたディレクトリー (``$ANSIBLE_LIBRARY`` は ``$PATH``のようにコロンで区切った一覧)"

#~ msgid "``~/.ansible/plugins/modules/``"
#~ msgstr "``~/.ansible/plugins/modules/``"

#~ msgid "``/usr/share/ansible/plugins/modules/``"
#~ msgstr "``/usr/share/ansible/plugins/modules/``"

#~ msgid "or"
#~ msgstr "または"

#~ msgid "You can limit the availability of your local module. If you want to use a local module only with selected playbooks or only with a single role, load it in one of the following locations:"
#~ msgstr "ローカルモジュールの可用性を制限することができます。選択した Playbook でのみローカルモジュールを使用する場合、または単一のロールでのみローカルモジュールを使用する場合は、以下のいずれかの場所にロードします。"

#~ msgid "Adding a plugin locally"
#~ msgstr "プラグインをローカルで追加"

#~ msgid "Ansible loads plugins automatically too, and loads each type of plugin separately from a directory named for the type of plugin. Here's the full list of plugin directory names:"
#~ msgstr "Ansible はプラグインも自動的にロードし、プラグインのタイプに対して名前が付けられたディレクトリーとは別に、各タイプのプラグインを読み込みます。プラグインディレクトリー名の全一覧を以下に示します。"

#~ msgid "cache_plugins"
#~ msgstr "cache_plugins"

#~ msgid "callback_plugins"
#~ msgstr "callback_plugins"

#~ msgid "connection_plugins"
#~ msgstr "connection_plugins"

#~ msgid "filter_plugins*"
#~ msgstr "filter_plugins*"

#~ msgid "inventory_plugins"
#~ msgstr "inventory_plugins"

#~ msgid "lookup_plugins"
#~ msgstr "lookup_plugins"

#~ msgid "shell_plugins"
#~ msgstr "shell_plugins"

#~ msgid "strategy_plugins"
#~ msgstr "strategy_plugins"

#~ msgid "test_plugins*"
#~ msgstr "test_plugins*"

#~ msgid "vars_plugins"
#~ msgstr "vars_plugins"

#~ msgid "After you add the plugins and verify that they are available for use, you can see the documentation for all the plugins except for the ones marked with an asterisk (*) above."
#~ msgstr "プラグインを追加して、それらが使用できることを確認すると、上記のアスタリスク (*) のマークが付いたものを除き、すべてのプラグインのドキュメントを表示できます。"

#~ msgid "To load your local plugins automatically, add them in any of these locations:"
#~ msgstr "ローカルプラグインを自動的に読み込むには、以下のいずれかの場所に追加します。"

#~ msgid "any directory added to the relevant ``ANSIBLE_plugin_type_PLUGINS`` environment variable (these variables, such as ``$ANSIBLE_INVENTORY_PLUGINS`` and ``$ANSIBLE_VARS_PLUGINS`` take colon-separated lists like ``$PATH``)"
#~ msgstr "関連する ``ANSIBLE_plugin_type_PLUGINS`` 環境変数に追加されたディレクトリー (``$ANSIBLE_INVENTORY_PLUGINS``、``$ANSIBLE_VARS_PLUGINS`` など) は、``$PATH`` のようにコロンで区切った一覧を取ります。"

#~ msgid "the directory named for the correct ``plugin_type`` within ``~/.ansible/plugins/`` - for example, ``~/.ansible/plugins/callback``"
#~ msgstr "``~/.ansible/plugins/`` 内の正しい ``plugin_type`` という名前のディレクトリー (例: ``~/.ansible/plugins/callback``)"

#~ msgid "the directory named for the correct ``plugin_type`` within ``/usr/share/ansible/plugins/`` - for example, ``/usr/share/ansible/plugins/action``"
#~ msgstr "``/usr/share/ansible/plugins/`` 内の正しい ``plugin_type`` という名前のディレクトリー (例: ``/usr/share/ansible/plugins/action``)"

#~ msgid "type ``ansible-doc -t <plugin_type> my_custom_lookup_plugin``. For example, ``ansible-doc -t lookup my_custom_lookup_plugin``. You should see the documentation for that plugin. This works for all plugin types except the ones marked with ``*`` in the list above  - see :ref:`ansible-doc` for more details."
#~ msgstr "``ansible-doc -t <plugin_type> my_custom_lookup_plugin`` を入力します (例: ``ansible-doc -t lookup my_custom_lookup_plugin``)。そのプラグインに関するドキュメントを確認してください。これは上記のリストで ``*`` のマークが付いたもの以外のすべてのプラグインタイプで機能します。詳細は「:ref:`ansible-doc`」を参照してください。"

#~ msgid "You can limit the availability of your local plugin. If you want to use a local plugin only with selected playbooks or only with a single role, load it in one of the following locations:"
#~ msgstr "ローカルプラグインの可用性を制限することができます。選択した Playbook でのみローカルプラグインを使用する場合、または単一のロールでのみローカルプラグインを使用する場合は、以下のいずれかの場所に読み込みます。"

#~ msgid "In a selected playbook or playbooks: Store the plugin in a subdirectory for the correct ``plugin_type`` (for example, ``callback_plugins`` or ``inventory_plugins``) in the directory that contains the playbooks."
#~ msgstr "選択した Playbook: そのPlaybook を含むディレクトリーに、正しい ``plugin_type`` (例: ``callback_plugins`` または ``inventory_plugins``) のサブディレクトリーにプラグインを保存します。"

#~ msgid "In a single role: Store the plugin in a subdirectory for the correct ``plugin_type`` (for example, ``cache_plugins`` or ``strategy_plugins``) within that role. When shipped as part of a role, the plugin is available as soon as the role is executed."
#~ msgstr "単一のロール: そのロール内で、正しい ``plugin_type`` （例： ``cache_plugins`` または ``strategy_plugins``) のサブディレクトリーにプラグインを保存します。ロールの一部として提供されると、ロールが実行されるとすぐにプラグインが利用可能になります。"

#~ msgid "Follow additional guidelines that apply to families of modules if applicable. For example, AWS modules should follow the  :ref:`Amazon development checklist <AWS_module_development>`."
#~ msgstr "該当する場合は、モジュールのファミリーに適用される追加のガイドラインに従います。たとえば、AWS モジュールは :ref:`Amazon development checklist <AWS_module_development>` に従う必要があります。"

#~ msgid "Please make sure your module meets these requirements before you submit your PR/proposal. If you have questions, reach out via `Ansible's IRC chat channel <http://irc.freenode.net>`_ or the `Ansible development mailing list <https://groups.google.com/group/ansible-devel>`_."
#~ msgstr "PR/提案を送信する前に、お使いのモジュールがこれらの要件を満たしていることを確認してください。ご質問がある場合は、`Ansible の IRC チャットチャンネル <http://irc.freenode.net>`_ または `Ansible 開発メーリングリスト <https://groups.google.com/group/ansible-devel>`_ までお問い合わせください。"

#~ msgid ":ref:`Amazon development checklist <AWS_module_development>`."
#~ msgstr ":ref:`Amazon 開発チェックリスト <AWS_module_development>`"

#~ msgid "Major additions to the module (for instance, rewrites) may add additional copyright lines. Any legal review will include the source control history, so an exhaustive copyright header is not necessary. Please do not edit the existing copyright year. This simplifies project administration and is unlikely to cause any interesting legal issues. When adding a second copyright line for a significant feature or rewrite, add the newer line above the older one:"
#~ msgstr "モジュールへの主要な追加 (たとえば、書き換え) は、により、著作権行が追加される場合があります。法的な審査にはソース管理履歴が含まれるため、網羅的な著作権ヘッダーは必要ありません。既存の著作権年は編集しないでください。これは、プロジェクトの管理を単純化するものであり、興味深い法的問題を引き起こす可能性はほとんどありません。重要な機能や書き換えのために 2 行目の著作権行を追加する場合は、古い行の上に新しい行を追加します。"

#~ msgid "``L()`` for links with a heading. For example: ``See L(Ansible Tower,https://www.ansible.com/products/tower).`` As of Ansible 2.10, do not use ``L()`` for relative links between Ansible documentation and collection documentation."
#~ msgstr "``L()`` 見出しへのリンク。たとえば、``See L(Ansible Tower,https://www.ansible.com/products/tower).`` となります。Ansible 2.10 以降、Ansible ドキュメントとコレクションのドキュメントの相対リンクには ``L()`` を使用しないでください。"

#~ msgid "Installing prerequisites via apt (Ubuntu)"
#~ msgstr "apt (Ubuntu) を使用した前提条件のインストール"

#~ msgid "Due to dependencies (for example ansible -> paramiko -> pynacl -> libffi):"
#~ msgstr "依存関係のため (例: ansible -> paramiko -> pynacl -> libffi)。"

#~ msgid "Creating a development environment (platform-agnostic steps)"
#~ msgstr "開発環境の作成 (プラットフォームに依存しない手順)"

#~ msgid "Clone the Ansible repository: ``$ git clone https://github.com/ansible/ansible.git``"
#~ msgstr "Ansible リポジトリーのクローンを作成します (``$ git clone https://github.com/ansible/ansible.git``)。"

#~ msgid "Change directory into the repository root dir: ``$ cd ansible``"
#~ msgstr "ディレクトリーをリポジトリーの root ディレクトリーに変更します (``$ cd ansible``)。"

#~ msgid "Create a virtual environment: ``$ python3 -m venv venv`` (or for Python 2 ``$ virtualenv venv``. Note, this requires you to install the virtualenv package: ``$ pip install virtualenv``)"
#~ msgstr "仮想環境を作成します (``$ python3 -m venv venv``) (Python 2 の場合は ``$ virtualenv venv`` です。これには、virtualenv パッケージ ``$ pip install virtualenv`` をインストールする必要があります。"

#~ msgid "Activate the virtual environment: ``$ . venv/bin/activate``"
#~ msgstr "仮想環境をアクティベートします (``$ . venv/bin/activate``)。"

#~ msgid "Install development requirements: ``$ pip install -r requirements.txt``"
#~ msgstr "開発要件をインストールします (``$ pip install -r requirements.txt``)。"

#~ msgid "Run the environment setup script for each new dev shell process: ``$ . hacking/env-setup``"
#~ msgstr "新規 dev シェルプロセスごとに環境設定スクリプトを実行します (``$ . hacking/env-setup``)。"

#~ msgid "After the initial setup above, every time you are ready to start developing Ansible you should be able to just run the following from the root of the Ansible repo: ``$ . venv/bin/activate && . hacking/env-setup``"
#~ msgstr "上記の初期設定後、Ansible の開発準備ができるたびに、Ansible リポジトリーのルートから ``$ . venv/bin/activate && . hacking/env-setup`` を実行できるはずです。"

#~ msgid "To create an info module:"
#~ msgstr "info モジュールを作成するには、次を実行します。"

#~ msgid "Navigate to the correct directory for your new module: ``$ cd lib/ansible/modules/``. If you are developing module using collection, ``$ cd plugins/modules/`` inside your collection development tree."
#~ msgstr "新しいモジュールの正しいディレクトリーに移動します (``$ cd lib/ansible/modules/``)。コレクションを使用してモジュールを開発する場合は、コレクション開発ツリー内で ``$ cd plugins/modules/`` を実行します。"

#~ msgid "Create your new module file: ``$ touch my_test_info.py``."
#~ msgstr "新しいモジュールファイルを作成します (``$ touch my_test_info.py``)。"

#~ msgid "Paste the content below into your new info module file. It includes the :ref:`required Ansible format and documentation <developing_modules_documenting>`, a simple :ref:`argument spec for declaring the module options <argument_spec>`, and some example code."
#~ msgstr "以下の内容を新しい情報モジュールファイルに貼り付けます。これには、:ref:`必須の Ansible 形式およびドキュメント <developing_modules_documenting>`、:ref:`モジュールオプションを宣言する単純な引数仕様 <argument_spec>`、およびサンプルコードが含まれます。"

#~ msgid "Modify and extend the code to do what you want your new info module to do. See the :ref:`programming tips <developing_modules_best_practices>` and :ref:`Python 3 compatibility <developing_python_3>` pages for pointers on writing clean and concise module code."
#~ msgstr "新しい情報モジュールが実行することを行えるようにコードを変更し、拡張します。余計なものが入っていないモジュールコードや、簡潔なモジュールコードの作成に関するヒントは、「:ref:`プログラミングのヒント <developing_modules_best_practices>`」ページおよび「:ref:`Python 3 互換性 <developing_python_3>`」ページを参照してください。"

#~ msgid "Navigate to the correct directory for your new module: ``$ cd lib/ansible/modules/``. If you are developing a module in a :ref:`collection <developing_collections>`, ``$ cd plugins/modules/`` inside your collection development tree."
#~ msgstr "新しいモジュールの正しいディレクトリーに移動します (``$ cd lib/ansible/modules/``)。:ref:`コレクション <developing_collections>` でモジュールを開発する場合は、コレクション開発ツリー内で ``$ cd plugins/modules/`` を実行します。"

#~ msgid "If you are using a virtual environment (which is highly recommended for development) activate it: ``$ . venv/bin/activate``"
#~ msgstr "(開発に非常に推奨されている) 仮想環境を使用している場合は、アクティベートします (``$ . venv/bin/activate``)。"

#~ msgid "Set up the environment for development: ``$ . hacking/env-setup``"
#~ msgstr "開発用の環境を設定します (``$ . hacking/env-setup``)。"

#~ msgid "Run your test module locally and directly: ``$ python -m ansible.modules.my_test /tmp/args.json``"
#~ msgstr "テストモジュールをローカルで直接実行します (``$ python -m ansible.modules.my_test /tmp/args.json``)。"

#~ msgid "The next step in verifying your new module is to consume it with an Ansible playbook."
#~ msgstr "新規モジュールを検証する次のステップは、Ansible Playbook で使用します。"

#~ msgid "You can add unit tests for your module in ``./test/units/modules``. You must first set up your testing environment. In this example, we're using Python 3.5."
#~ msgstr "モジュールのユニットテストは ``./test/units/modules`` で追加できます。まずテスト環境を設定する必要があります。この例では、Python 3.5 を使用しています。"

#~ msgid "Install the requirements (outside of your virtual environment): ``$ pip3 install -r ./test/lib/ansible_test/_data/requirements/units.txt``"
#~ msgstr "(仮想環境外に) 要件をインストールします (``$ pip3 install -r ./test/lib/ansible_test/_data/requirements/units.txt``)。"

#~ msgid "Run ``. hacking/env-setup``"
#~ msgstr "``. hacking/env-setup`` を実行します。"

#~ msgid "To run all tests do the following: ``$ ansible-test units --python 3.5``. If you are using a CI environment, these tests will run automatically."
#~ msgstr "すべてのテストを実行するには、``$ ansible-test units --python 3.5`` で CI 環境を使用している場合は、これらのテストが自動的に実行されます。"

#~ msgid "Ansible uses pytest for unit testing."
#~ msgstr "Ansible はユニットテストに pytest を使用します。"

#~ msgid "To run pytest against a single test module, you can run the following command. Ensure that you are providing the correct path of the test module:"
#~ msgstr "単一のテストモジュールに対して pytest を実行するには、以下のコマンドを実行します。テストモジュールの正しいパスを提供していることを確認してください。"

#~ msgid "``$ pytest -r a --cov=. --cov-report=html --fulltrace --color yes test/units/modules/.../test/my_test.py``"
#~ msgstr "``$ pytest -r a --cov=. --cov-report=html --fulltrace --color yes test/units/modules/.../test/my_test.py``"

#~ msgid "Join the IRC channel ``#ansible-devel`` on freenode for discussions surrounding Ansible development."
#~ msgstr "Ansible 開発に取り組むため、freenode の IRC チャンネル ``#ansible-devel`` に参加します。"

#~ msgid "`jborean93/WindowsServer2008-x86 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2008-x86>`_"
#~ msgstr "`jborean93/WindowsServer2008-x86 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2008-x86>`_"

#~ msgid "`jborean93/WindowsServer2008-x64 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2008-x64>`_"
#~ msgstr "`jborean93/WindowsServer2008-x64 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2008-x64>`_"

#~ msgid "`jborean93/WindowsServer2008R2 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2008R2>`_"
#~ msgstr "`jborean93/WindowsServer2008R2 <https://app.vagrantup.com/jborean93/boxes/WindowsServer2008R2>`_"

#~ msgid "While an SSH server is available on all Windows hosts but Server 2008 (non R2), it is not a support connection for Ansible managing Windows hosts and should not be used with Ansible."
#~ msgstr "SSH サーバーはすべての Windows ホストで利用できますが、Server 2008 (R2 以外) は、Ansible による Windows ホストの管理接続ではなく、Ansible では使用できません。"

#~ msgid "Join the IRC channel ``#ansible-devel`` or ``#ansible-windows`` on freenode for discussions about Ansible development for Windows."
#~ msgstr "freenode の IRC チャネル ``#ansible-devel`` または ``#ansible-windows`` に参加し、Windows 用 の Ansible 開発に関する議論を行うこと。"

#~ msgid "``#ansible-devel`` - We have found that IRC ``#ansible-devel`` on FreeNode's IRC network works best for developers so we can have an interactive dialogue."
#~ msgstr "``#ansible-devel`` - FreeNode の IRC ネットワーク ``#ansible-devel`` では、インタラクティブな対話を行うことができるため、モジュール開発者に最適なものであることが分かっています。"

#~ msgid "If you need help or advice, consider join the ``#ansible-devel`` IRC channel (see how in the \"Where to get support\")."
#~ msgstr "さらにヘルプまたはアドバイスが必要な場合は、IRC チャンネル ``#ansible-devel`` に参加することを検討してください (「サポートを得る方法」を参照してください)。"

#~ msgid "Lookup plugins are very flexible, allowing you to retrieve and return any type of data. When writing lookup plugins, always return data of a consistent type that can be easily consumed in a playbook. Avoid parameters that change the returned data type. If there is a need to return a single value sometimes and a complex dictionary other times, write two different lookup plugins."
#~ msgstr "Lookup プラグインは非常に柔軟性があるため、あらゆるタイプのデータを取得し、返すことができます。Lookup プラグインを記述する際には、Playbook で簡単に使用できる一貫性のあるタイプのデータを常に返します。返されたデータ型を変更するパラメーターは使用しないでください。単一の値を返さなければならないときもあれば、複雑なディクショナリーを返さなければない場合もあります。この場合は、Lookup プラグインを 2 つ記述してください。"

#~ msgid "You can create vars plugins that are not enabled by default using the class variable ``REQUIRES_ENABLED``. If your vars plugin resides in a collection, it cannot be enabled by default. You must use ``REQUIRES_ENABLED`` in all collections-based vars plugins. To require users to enable your plugin, set the class variable ``REQUIRES_ENABLED``:"
#~ msgstr "クラス変数 ``REQUIRES_ENABLED`` を使用して、デフォルトで有効になっていない vars プラグインを作成できます。vars プラグインがコレクションに存在する場合は、デフォルトで有効にはできません。すべてのコレクションベースの vars プラグインで ``REQUIRES_ENABLED`` を使用する必要があります。ユーザーがプラグインを有効にするには、クラス変数 ``REQUIRES_ENABLED`` を設定します。"

#~ msgid "``removed_in_version`` indicates which version of ansible-base or a collection a deprecated argument will be removed in. Mutually exclusive with ``removed_at_date``, and must be used with ``removed_from_collection``."
#~ msgstr "``removed_in_version`` は、非推奨の引数が削除される ansible-base またはコレクションのバージョンを示します。``removed_at_date`` で相互排他され、``removed_from_collection`` で使用する必要があります。"

#~ msgid "``removed_at_date`` indicates that a deprecated argument will be removed in a minor ansible-base release or major collection release after this date. Mutually exclusive with ``removed_in_version``, and must be used with ``removed_from_collection``."
#~ msgstr "``removed_at_date`` は、非推奨の引数が、この日付以降のマイナーな ansible-base リリースまたはメジャーコレクションリリースで削除されることを示します。``removed_in_version`` と相互に排他的であり、``removed_from_collection`` と一緒に使用する必要があります。"

#~ msgid "The ``ansible-base`` code runs on both Python 2 and Python 3 because we want Ansible to be able to manage a wide variety of machines. Contributors to ansible-base and to Ansible Collections should be aware of the tips in this document so that they can write code that will run on the same versions of Python as the rest of Ansible."
#~ msgstr "Ansible が各種マシンを管理できるようにするため、``ansible-base`` コードは Python 2 と Python 3 の両方で実行されます。Ansible ベースと Ansible Collections では、Ansible の残りの部分と同じバージョンの Python で実行されるコードを記述できる必要があります。"

#~ msgid "To ensure that your code runs on Python 3 as well as on Python 2, learn the tips and tricks and idioms described here. Most of these considerations apply to all three types of Ansible code:"
#~ msgstr "Python 2 および Python 2 でコードが実行されるようにするには、ここで説明するヒントとコツ、およびイディオムを確認してください。これらの考慮事項は、これら 3 種類の Ansible コードのすべてに適用されます。"

#~ msgid "On the controller we support Python 3.5 or greater and Python 2.7 or greater.  Module-side, we support Python 3.5 or greater and Python 2.6 or greater."
#~ msgstr "コントローラーでは、Python 3.5 以降、および Python 2.7 以降をサポートしています。モジュール側では、Python 3.5 以降、Python 2.6 以降をサポートします。"

#~ msgid "Python 3.5 was chosen as a minimum because it is the earliest Python 3 version adopted as the default Python by a Long Term Support (LTS) Linux distribution (in this case, Ubuntu-16.04). Previous LTS Linux distributions shipped with a Python 2 version which users can rely upon instead of the Python 3 version."
#~ msgstr "Python 3.5 は、長期サポート (LTS: Long Term Support) の Linux ディストリビューション (この場合は Ubuntu-16.04) でデフォルトの Python として採用されている最も古い Python 3 のバージョンであるため、最小バージョンとして採用されました。以前の LTS Linux ディストリビューションでは、Python 3 バージョンの代わりに、ユーザーが代わりに使用できる Python 2 バージョンが同梱されていました。"

#~ msgid "For Python 2, the default is for modules to run on at least Python 2.6.  This allows users with older distributions that are stuck on Python 2.6 to manage their machines.  Modules are allowed to drop support for Python 2.6 when one of their dependent libraries requires a higher version of Python. This is not an invitation to add unnecessary dependent libraries in order to force your module to be usable only with a newer version of Python; instead it is an acknowledgment that some libraries (for instance, boto3 and docker-py) will only function with a newer version of Python."
#~ msgstr "Python 2 では、モジュールは少なくとも Python 2.6 で動作することがデフォルトとなっています。これにより、Python 2.6 に固執する古いディストリビューションのユーザーが自分のマシンを管理できるようになります。モジュールは、依存するライブラリーの 1 つがより高いバージョンの Python を必要とする場合は、Python 2.6 のサポートを終了することができます。これは、自作したモジュールをより新しいバージョンの Python でしか使えないようにするために、不要な依存ライブラリーを追加することを勧めるものではありません。代わりに、いくつかのライブラリー (例えば、boto3 や docker-py) はより新しいバージョンの Python でしか機能しないことを認めています。"

#~ msgid "Python 2.4 Module-side Support:"
#~ msgstr "Python 2.4 モジュールでのサポート:"

#~ msgid "Support for Python 2.4 and Python 2.5 was dropped in Ansible-2.4.  RHEL-5 (and its rebuilds like CentOS-5) were supported until April of 2017. Ansible-2.3 was released in April of 2017 and was the last Ansible release to support Python 2.4 on the module-side."
#~ msgstr "Python 2.4 および Python 2.5 のサポートは Ansible-2.4 から削除されました。RHEL-5 (および CentOS-5) は 2017 年 4 月までサポートされます。Ansible-2.3 は 2017 年 4 月にリリースされ、モジュールサイドの Python 2.4 をサポートする最後の Ansible リリースでした。"

#~ msgid "Testing modules on Python 3"
#~ msgstr "Python 3 でのモジュールのテスト"

#~ msgid "Ansible modules are slightly harder to code to support Python 3 than normal code from other projects. A lot of mocking has to go into unit testing an Ansible module, so it's harder to test that your changes have fixed everything or to to make sure that later commits haven't regressed the Python 3 support. Review our :ref:`testing <developing_testing>` pages for more information."
#~ msgstr "Ansible モジュールは、その他のプロジェクトの通常のコードよりも Python 3 をサポートするようにコーディングするのが若干難しくなります。多くのモックは、Ansible モジュールのユニットテストに入る必要があるため、変更によってすべてが修正されたことをテストするか、後のコミットが Python 3 をサポートしないようにする方が困難になります。詳細は、:ref:`テスト <developing_testing>` ページを参照してください。"

#~ msgid "an :ref:`Amazon module <AWS_module_development>`."
#~ msgstr ":ref:`Amazon モジュール <AWS_module_development>`"

#~ msgid "a :ref:`VMware module <VMware_module_development>`."
#~ msgstr ":ref:`VMware モジュール <VMware_module_development>`"

#~ msgid "If a module matures, we will remove the 'preview' mark in the documentation. We support (though we cannot guarantee) backwards compatibility for these modules, which means their parameters should be maintained with stable meanings."
#~ msgstr "モジュールが成熟すると、ドキュメントの「プレビュー」マークが削除されます。これらのモジュールに対する後方互換性はサポートします (が保証はしません)。つまり、パラメーターは安定した方法で維持する必要があります。"

#~ msgid "When a module has been deprecated for four release cycles, we remove the code and mark the stub file removed. Modules that are removed are no longer shipped with Ansible. The stub file helps users find alternative modules."
#~ msgstr "4 つのリリースサイクルでモジュールが非推奨になったら、コードを削除し、stab ファイルに removed と表示します。削除されたモジュールは、Ansible に同梱されなくなります。stab ファイルは、ユーザーが代替モジュールを見つけるのに役立ちます。"

#~ msgid "Deprecating modules"
#~ msgstr "モジュールの非推奨化"

#~ msgid "Mention the deprecation in the relevant ``CHANGELOG``."
#~ msgstr "関連する ``CHANGELOG`` の非推奨に言及してください。"

#~ msgid "note: with the advent of collections and ``routing.yml`` we might soon require another entry in this file to mark the deprecation."
#~ msgstr "注記: コレクションおよび ``routing.yml`` では、非推奨となったマークにこのファイル内の別のエントリーがすぐに必要になることがあります。"

#~ msgid "Changing a module name"
#~ msgstr "モジュール名の変更"

#~ msgid "The Ansible AWS collection (on `Galaxy <https://galaxy.ansible.com/community/aws>`_, source code `repository <https://github.com/ansible-collections/community.aws>`_) is maintained by the Ansible AWS Working Group.  For further information see the `AWS working group community page <https://github.com/ansible/community/wiki/aws>`_. If you are planning to contribute AWS modules to Ansible then getting in touch with the working group is a good way to start, especially because a similar module may already be under development."
#~ msgstr "Ansible AWS コレクション (`Galaxy <https://galaxy.ansible.com/community/aws>`_ では、ソースコード `レポジトリー <https://github.com/ansible-collections/community.aws>`_) は、Ansible AWS のワーキンググループ維持されます。詳細は `AWS ワーキンググループのコミュニティーページ <https://github.com/ansible/community/wiki/aws>`_ を参照してください。AWS モジュールを Ansible に提供することを計画している場合は、特に同様のモジュールがすでに開発中である可能性があるため、ワーキンググループに連絡することから始めることを推奨します。"

#~ msgid "Maintaining existing modules"
#~ msgstr "既存のモジュールのメンテナンス"

#~ msgid "Fixing bugs"
#~ msgstr "バグの修正"

#~ msgid "Bug fixes to code that relies on boto will still be accepted. When possible, the code should be ported to use boto3."
#~ msgstr "boto に依存するコードに対するバグ修正は引き続き承認されます。可能であれば、このコードは、boto3 を使用するように移植する必要があります。"

#~ msgid "Adding new features"
#~ msgstr "新しい機能の追加"

#~ msgid "Try to keep backward compatibility with relatively recent versions of boto3. That means that if you want to implement some functionality that uses a new feature of boto3, it should only fail if that feature actually needs to be run, with a message stating the missing feature and minimum required version of boto3."
#~ msgstr "比較的最近のバージョンの boto3 との下位互換性を保つようにしてください。つまり、boto3 の新機能を使用する一部の機能を実装する場合は、その機能を実際に実行する必要がある場合にのみ失敗し、欠落している機能と最低限必要な boto3 のバージョンを示すメッセージが表示されます。"

#~ msgid "Use feature testing (for example, ``hasattr('boto3.module', 'shiny_new_method')``) to check whether boto3 supports a feature rather than version checking. For example, from the ``ec2`` module:"
#~ msgstr "機能テスト (例: ``hasattr('boto3.module', 'shiny_new_method')``) を使用して、boto3 がバージョンチェックではなく機能をサポートしているかどうかを確認します。たとえば、``ec2`` モジュールからです。"

#~ msgid "Migrating to boto3"
#~ msgstr "boto3 への移行"

#~ msgid "Prior to Ansible 2.0, modules were written in either boto3 or boto. We are still porting some modules to boto3. Modules that still require boto should be ported to use boto3 rather than using both libraries (boto and boto3). We would like to remove the boto dependency from all modules."
#~ msgstr "Ansible 2.0 より前、モジュールは boto3 または boto のいずれかで記述されていました。まだ、いくつかのモジュールを boto3 に移植しています。それでもbotoが必要なモジュールは、両方のライブラリー (boto と boto3) を使用するのではなく、boto3 を使用するように移植する必要があります。すべてのモジュールから boto 依存関係を削除したいと考えています。"

#~ msgid "Porting code to AnsibleAWSModule"
#~ msgstr "AnsibleAWSModule へのコードの移植"

#~ msgid "Some old AWS modules use the generic ``AnsibleModule`` as a base rather than the more efficient ``AnsibleAWSModule``. To port an old module to ``AnsibleAWSModule``, change:"
#~ msgstr "一部の古い AWS モジュールは、より効率的な ``AnsibleAWSModule`` ではなく、汎用の ``AnsibleModule`` をベースとして使用します。古いモジュールを ``AnsibleAWSModule`` に移植するには、以下を変更します。"

#~ msgid "to:"
#~ msgstr "以下のように変更します。"

#~ msgid "Few other changes are required. AnsibleAWSModule does not inherit methods from AnsibleModule by default, but most useful methods are included. If you do find an issue, please raise a bug report."
#~ msgstr "その他の変更が必要になります。AnsibleAWSModule はデフォルトで AnsibleModule のメソッドを継承しませんが、最も便利なメソッドが含まれています。問題を発見した場合は、バグレポートを提出してください。"

#~ msgid "When porting, keep in mind that AnsibleAWSModule also will add the default ec2 argument spec by default. In pre-port modules, you should see common arguments specified with:"
#~ msgstr "ポート時には、AnsibleAWSModule はデフォルトでデフォルトの ec2 引数仕様も追加します。事前ポートモジュールでは、以下で指定された一般的な引数が表示されるはずです。"

#~ msgid "These can be replaced with:"
#~ msgstr "これは、次のものと置き換えることができます。"

#~ msgid "Creating new AWS modules"
#~ msgstr "新規 AWS モジュールの作成"

#~ msgid "Use boto3 and AnsibleAWSModule"
#~ msgstr "boto3 および AnsibleAWSModule の使用"

#~ msgid "All new AWS modules must use boto3 and ``AnsibleAWSModule``."
#~ msgstr "すべての新規 AWS モジュールは boto3 および ``AnsibleAWSModule`` を使用する必要があります。"

#~ msgid "``AnsibleAWSModule`` greatly simplifies exception handling and library management, reducing the amount of boilerplate code. If you cannot use ``AnsibleAWSModule`` as a base, you must document the reason and request an exception to this rule."
#~ msgstr "``AnsibleAWSModule`` は、例外処理とライブラリー管理を大幅に簡素化し、ボイラープレートコードの量を削減します。``AnsibleAWSModule`` をベースとして使えない場合は、理由を文書化し、このルールの例外を要求する必要があります。"

#~ msgid "Naming your module"
#~ msgstr "モジュールの名前付け"

#~ msgid "Base the name of the module on the part of AWS that you actually use. (A good rule of thumb is to take whatever module you use with boto as a starting point).  Don't further abbreviate names - if something is a well known abbreviation of a major component of AWS (for example, VPC or ELB), that's fine, but don't create new ones independently."
#~ msgstr "実際に使用する AWS の一部であるモジュール名をベースにします (経験則として、boto で使用するモジュールを開始点として使用することが推奨されます)。名前をさらに省略しないでください。AWS の主要コンポーネント (VPC や ELB など) のよく知られた省略形である場合は問題ありませんが、新しい名前を個別に作成しないでください。"

#~ msgid "Unless the name of your service is quite unique, please consider using ``aws_`` as a prefix. For example ``aws_lambda``."
#~ msgstr "サービスの名前が非常に一意でない限り、``aws_`` を接頭辞として使用することを検討してください。たとえば、``aws_lambda`` となります。"

#~ msgid "Importing botocore and boto3"
#~ msgstr "botocore および boto3 のインポート"

#~ msgid "The ``ansible.module_utils.ec2`` module and ``ansible.module_utils.core.aws`` modules both automatically import boto3 and botocore.  If boto3 is missing from the system then the variable ``HAS_BOTO3`` will be set to false.  Normally, this means that modules don't need to import boto3 directly. There is no need to check ``HAS_BOTO3`` when using AnsibleAWSModule as the module does that check:"
#~ msgstr "``ansible.module_utils.ec2`` モジュールと ``ansible.module_utils.core.aws`` モジュールは、boto3 と botocore を自動的にインポートします。 システムに boto3 がない場合は、変数 ``HAS_BOTO3`` が false に設定されます。通常、これは、boto3 を直接インポートする必要はありません。モジュールの確認が行われる際に AnsibleAWSModule を使用する場合は、``HAS_BOTO3`` を確認する必要はありません。"

#~ msgid "or:"
#~ msgstr "または"

#~ msgid "Supporting Module Defaults"
#~ msgstr "モジュールのデフォルトのサポート"

#~ msgid "The existing AWS modules support using :ref:`module_defaults <module_defaults>` for common authentication parameters.  To do the same for your new module, add an entry for it in ``lib/ansible/config/module_defaults.yml``.  These entries take the form of:"
#~ msgstr "既存の AWS モジュールは、共通の認証パラメーターに :ref:`module_defaults <module_defaults>` を使用したサポートです。新しいモジュールに同じモジュールを行うには、``lib/ansible/config/module_defaults.yml`` でエントリーを追加します。これらのエントリーは以下の形式になります。"

#~ msgid "Connecting to AWS"
#~ msgstr "AWS への接続"

#~ msgid "AnsibleAWSModule provides the ``resource`` and ``client`` helper methods for obtaining boto3 connections. These handle some of the more esoteric connection options, such as security tokens and boto profiles."
#~ msgstr "AnsibleAWSModule は、boto3 接続を取得するためのヘルパーメソッド ``resource`` および ``client`` を提供します。これらは、セキュリティートークンや boto プロファイルなど、より難解な接続オプションのいくつかを処理します。"

#~ msgid "If using the basic AnsibleModule then you should use ``get_aws_connection_info`` and then ``boto3_conn`` to connect to AWS as these handle the same range of connection options."
#~ msgstr "接続オプションと同じ範囲を処理するため、基本的な AnsibleModule を使用する場合は、``get_aws_connection_info`` を使用してから ``boto3_conn`` を使用して AWS に接続する必要があります。"

#~ msgid "These helpers also for missing profiles or a region not set when it needs to be, so you don't have to."
#~ msgstr "これらのヘルパーは、欠落しているプロファイルや、必要なときに設定されていない領域にも使用できるため、必須ではありません。"

#~ msgid "An example of connecting to ec2 is shown below. Note that unlike boto there is no ``NoAuthHandlerFound`` exception handling like in boto. Instead, an ``AuthFailure`` exception will be thrown when you use the connection. To ensure that authorization, parameter validation and permissions errors are all caught, you should catch ``ClientError`` and ``BotoCoreError`` exceptions with every boto3 connection call. See exception handling:"
#~ msgstr "ec2 への接続例は以下のようになります。boto とは異なり、boto には、``NoAuthHandlerFound`` の例外処理がないことに注意してください。代わりに、接続の使用時に ``AuthFailure`` 例外がスローされます。承認、パラメーター検証およびパーミッションエラーがすべてキャッチされるようにするには、すべての boto3 接続呼び出しで ``ClientError`` および ``BotoCoreError`` の例外をキャッチする必要があります。「例外処理」を参照してください。"

#~ msgid "or for the higher level ec2 resource:"
#~ msgstr "また、より高いレベルの ec2 リソースの場合は、次のようになります。"

#~ msgid "An example of the older style connection used for modules based on AnsibleModule rather than AnsibleAWSModule:"
#~ msgstr "AnsibleAWSModule ではなく AnsibleModule に基づくモジュールに使用される旧式の接続例は次のとおりです。"

#~ msgid "Common Documentation Fragments for Connection Parameters"
#~ msgstr "接続パラメーターに関する断片化された汎用ドキュメント"

#~ msgid "There are two :ref:`common documentation fragments <module_docs_fragments>` that should be included into almost all AWS modules:"
#~ msgstr "ほとんどすべての AWS モジュールに含まれる :ref:`断片化された汎用ドキュメント <module_docs_fragments>` は 2 つあります。"

#~ msgid "``aws`` - contains the common boto connection parameters"
#~ msgstr "``aws`` - 共通の boto 接続パラメーターが含まれます。"

#~ msgid "``ec2`` - contains the common region parameter required for many AWS modules"
#~ msgstr "``ec2`` - 数多くの AWS モジュールに必要な共通の region パラメーターが含まれます。"

#~ msgid "These fragments should be used rather than re-documenting these properties to ensure consistency and that the more esoteric connection options are documented. For example:"
#~ msgstr "一貫性を確保し、より難解な接続オプションを文書化するには、このようなプロパティーを再文書化するのではなく、このような断片化されたドキュメントを使用する必要があります。たとえば、以下のようになります。"

#~ msgid "Handling exceptions"
#~ msgstr "例外の処理"

#~ msgid "You should wrap any boto3 or botocore call in a try block. If an exception is thrown, then there are a number of possibilities for handling it."
#~ msgstr "try ブロックで boto3 または botocore 呼び出しをラップする必要があります。例外がスローされると、処理の可能性が多数あります。"

#~ msgid "Catch the general ``ClientError`` or look for a specific error code with"
#~ msgstr "汎用的な ``ClientError`` を取得するか、次のような特定のエラーコードを探します"

#~ msgid "``is_boto3_error_code``."
#~ msgstr "``is_boto3_error_code``."

#~ msgid "Use ``aws_module.fail_json_aws()`` to report the module failure in a standard way"
#~ msgstr "``aws_module.fail_json_aws()`` を使用して、標準的な方法でモジュール障害を報告します。"

#~ msgid "Retry using AWSRetry"
#~ msgstr "AWSRetry を使用して再試行します。"

#~ msgid "Use ``fail_json()`` to report the failure without using ``ansible.module_utils.aws.core``"
#~ msgstr "``fail_json()`` を使用して、``ansible.module_utils.aws.core`` を使用せずに障害を報告します。"

#~ msgid "Do something custom in the case where you know how to handle the exception"
#~ msgstr "例外の処理方法が分かっている場合は、何らかのカスタマイズ作業を行います。"

#~ msgid "For more information on botocore exception handling see the `botocore error documentation <https://botocore.readthedocs.io/en/latest/client_upgrades.html#error-handling>`_."
#~ msgstr "botocore 例外処理の詳細は、`botocore エラードキュメント <https://botocore.readthedocs.io/en/latest/client_upgrades.html#error-handling>`_ を参照してください。"

#~ msgid "Using is_boto3_error_code"
#~ msgstr "is_boto3_error_code の使用"

#~ msgid "To use ``ansible.module_utils.aws.core.is_boto3_error_code`` to catch a single AWS error code, call it in place of ``ClientError`` in your except clauses. In this case, *only* the ``InvalidGroup.NotFound`` error code will be caught here, and any other error will be raised for handling elsewhere in the program."
#~ msgstr "``ansible.module_utils.aws.core.is_boto3_error_code`` を使用して単一の AWS エラーコードを取得するには、except 句で ``ClientError`` の代わりに呼び出しを行います。この場合、``InvalidGroup.NotFound`` エラーコードをここに検出し、その他のエラーでプログラム内の別の場所を処理する際に発生します。"

#~ msgid "Using fail_json_aws()"
#~ msgstr "fail_json_aws() の使用"

#~ msgid "In the AnsibleAWSModule there is a special method, ``module.fail_json_aws()`` for nice reporting of exceptions.  Call this on your exception and it will report the error together with a traceback for use in Ansible verbose mode."
#~ msgstr "AnsibleAWSModule には、例外レポートに優れた方法 ``module.fail_json_aws()`` があります。例外上でこの呼び出しを行い、Ansible の冗長モードで使用するためにトレースバックと共にエラーを報告します。"

#~ msgid "You should use the AnsibleAWSModule for all new modules, unless not possible. If adding significant amounts of exception handling to existing modules, we recommend migrating the module to use AnsibleAWSModule (there are very few changes required to do this)"
#~ msgstr "不可能でない限り、すべての新しいモジュールに AnsibleAWSModule を使用する必要があります。既存のモジュールに大量の例外処理を追加する場合は、AnsibleAWSModule を使用するようにモジュールを移行することが推奨されます (これを行うために必要な変更はほとんどありません)。"

#~ msgid "Note that it should normally be acceptable to catch all normal exceptions here, however if you expect anything other than botocore exceptions you should test everything works as expected."
#~ msgstr "通常、ここですべての通常の例外を捕えても問題がないことに注意してください。ただし、botocore 以外の例外が予想される場合は、すべてが期待どおりに機能するかどうかをテストする必要があります。"

#~ msgid "If you need to perform an action based on the error boto3 returned, use the error code."
#~ msgstr "返された boto3 エラーに基づいてアクションを実行する必要がある場合は、このエラーコードを使用します。"

#~ msgid "using fail_json() and avoiding ansible.module_utils.aws.core"
#~ msgstr "fail_json() and avoiding ansible.module_utils.aws.core の使用"

#~ msgid "Boto3 provides lots of useful information when an exception is thrown so pass this to the user along with the message."
#~ msgstr "Boto3 は、例外が発生したときに多くの有用な情報を提供するため、メッセージと共にこれをユーザーに渡します。"

#~ msgid "Note: we use `str(e)` rather than `e.message` as the latter doesn't work with python3"
#~ msgstr "注記: 後者は python3 では機能しないため、`e.message` の代わりに `str(e)` を使用します。"

#~ msgid "API throttling (rate limiting) and pagination"
#~ msgstr "API スロットリング (レート制限) とページネーション"

#~ msgid "For methods that return a lot of results, boto3 often provides `paginators <https://boto3.readthedocs.io/en/latest/guide/paginators.html>`_. If the method you're calling has ``NextToken`` or ``Marker`` parameters, you should probably check whether a paginator exists (the top of each boto3 service reference page has a link to Paginators, if the service has any). To use paginators, obtain a paginator object, call ``paginator.paginate`` with the appropriate arguments and then call ``build_full_result``."
#~ msgstr "大量の結果を返すメソッドの場合、boto3 はしばしば `paginators <https://boto3.readthedocs.io/en/latest/guide/paginators.html>`_ を提供します。呼び出しているメソッドに ``NextToken`` パラメーターまたは ``Marker`` パラメーターがある場合は、Paginator が存在するかどうかを確認する必要があります (各 boto3 サービスに paginator がある場合は、参照ページ上部に Paginator へのリンクがあります)。paginator を使用するには、paginator オブジェクトを取得し、適切な引数を指定して ``paginator.paginate`` を呼び出してから、``build_full_result`` を呼び出します。"

#~ msgid "Any time that you are calling the AWS API a lot, you may experience API throttling, and there is an ``AWSRetry`` decorator that can be used to ensure backoff. Because exception handling could interfere with the retry working properly (as AWSRetry needs to catch throttling exceptions to work correctly), you'd need to provide a backoff function and then put exception handling around the backoff function."
#~ msgstr "AWS API を大量に呼び出しているのはいつでも、API スロットリングが発生する可能性があり、バックオフ機能を提供するために使用できる ``AWSRetry`` デコレーターがあります。例外処理は再試行が正しく機能するのを妨げる可能性があるため (AWSRetry が正しく機能するためにスロットリング例外を取得する必要があるため)、バックオフ関数を提供してから、バックオフ関数の周りに例外処理を配置する必要があります。"

#~ msgid "You can use ``exponential_backoff`` or ``jittered_backoff`` strategies - see the cloud ``module_utils`` ()/lib/ansible/module_utils/cloud.py) and `AWS Architecture blog <https://www.awsarchitectureblog.com/2015/03/backoff.html>`_ for more details."
#~ msgstr "``exponential_backoff`` または ``jittered_backoff`` ストラテジーを使用できます。詳細は、クラウド ``module_utils`` ()/lib/ansible/module_utils/cloud.py) および `AWS アーキテクチャーのブログ <https://www.awsarchitectureblog.com/2015/03/backoff.html>`_ を参照してください。"

#~ msgid "The combination of these two approaches is then:"
#~ msgstr "これら 2 つのアプローチの組み合わせは次のとおりです。"

#~ msgid "If the underlying ``describe_some_resources`` API call throws a ``ResourceNotFound`` exception, ``AWSRetry`` takes this as a cue to retry until it's not thrown (this is so that when creating a resource, we can just retry until it exists)."
#~ msgstr "基礎となる ``describe_some_resources`` API 呼び出しで ``ResourceNotFound`` 例外を出力すると、``AWSRetry`` はこれが出力されなくなるまで再試行する合図としてこれを受け取ります (これは、リソースを作成するときに、リソースが存在するまで再試行できるようにするためです)。"

#~ msgid "To handle authorization failures or parameter validation errors in ``describe_some_resource_with_backoff``, where we just want to return ``None`` if the resource doesn't exist and not retry, we need:"
#~ msgstr "リソースが存在しない場合、およびリソースが再試行されていない場合のみ ``None`` を返す ``describe_some_resource_with_backoff`` で承認の失敗またはパラメーター検証エラーを処理するには、以下が必要になります。"

#~ msgid "To make use of AWSRetry easier, it can now be wrapped around a client returned by ``AnsibleAWSModule``. any call from a client. To add retries to a client, create a client:"
#~ msgstr "AWSRetry を使いやすくするために、``AnsibleAWSModule`` (クライアントからの呼び出し) によって返されたクライアントをラップできるようになりました。クライアントに再試行を追加するには、クライアントを作成します。"

#~ msgid "Any calls from that client can be made to use the decorator passed at call-time using the `aws_retry` argument. By default, no retries are used."
#~ msgstr "そのクライアントからの呼び出しはすべて、`aws_retry` 引数を使用して呼び出し時に渡されたデコレーターを使用して行うことができます。デフォルトでは、再試行は使用されません。"

#~ msgid "The call will be retried the specified number of times, so the calling functions don't need to be wrapped in the backoff decorator."
#~ msgstr "呼び出しは指定された回数だけ再試行されるため、呼び出し元の関数をバックオフデコレーターでラップする必要はありません。"

#~ msgid "You can also use customization for ``retries``, ``delay`` and ``max_delay`` parameters used by ``AWSRetry.jittered_backoff`` API using module params. You can take a look at the `cloudformation <cloudformation_module>` module for example."
#~ msgstr "また、モジュールパラメーターを使用して、``AWSRetry.jittered_backoff`` API が使用する ``retries`` パラメーター、``delay`` パラメーター、および ``max_delay`` パラメーターのカスタマイズを使用することもできます。たとえば、`cloudformation <cloudformation_module>` モジュールを参照してください。"

#~ msgid "To make all Amazon modules uniform, prefix the module param with ``backoff_``, so ``retries`` becomes ``backoff_retries``"
#~ msgstr "すべての Amazon モジュールを均一にするには、モジュールパラメーターの前に ``backoff_`` を付けます。これにより、``retries`` は ``backoff_retries`` になります。"

#~ msgid "and likewise with ``backoff_delay`` and ``backoff_max_delay``."
#~ msgstr "``backoff_delay`` と ``backoff_max_delay`` も同様です。"

#~ msgid "Returning Values"
#~ msgstr "戻り値"

#~ msgid "When you make a call using boto3, you will probably get back some useful information that you should return in the module.  As well as information related to the call itself, you will also have some response metadata.  It is OK to return this to the user as well as they may find it useful."
#~ msgstr "boto3 を使用して呼び出しを行うと、モジュールで返す必要がある便利な情報を入手できます。また、呼び出し自体に関連する情報や応答メタデータもあります。これをユーザーに返すことは問題ありませんが、ユーザーはそれが役立つと思うかもしれません。"

#~ msgid "Boto3 returns all values CamelCased.  Ansible follows Python standards for variable names and uses snake_case. There is a helper function in module_utils/ec2.py called `camel_dict_to_snake_dict` that allows you to easily convert the boto3 response to snake_case."
#~ msgstr "boto3 は、キャメルケース化したすべての値を返します。Ansible は変数名の Python 標準に従い、snake_case を使用します。`camel_dict_to_snake_dict` という名前の module_utils/ec2.py にヘルパー関数があり、boto3 を簡単に snake_case に変換できます。"

#~ msgid "You should use this helper function and avoid changing the names of values returned by Boto3. E.g. if boto3 returns a value called 'SecretAccessKey' do not change it to 'AccessKey'."
#~ msgstr "このヘルパー関数を使用し、Boto3 が返す値の名前を変更しないでください。たとえば、boto3 が「SecretAccessKey」値を返す場合は、これを「AccessKey」に変更しないでください。"

#~ msgid "Dealing with IAM JSON policy"
#~ msgstr "IAM JSON ポリシーの処理"

#~ msgid "If your module accepts IAM JSON policies then set the type to 'json' in the module spec. For example:"
#~ msgstr "モジュールが IAM JSON ポリシーを受け入れる場合は、モジュール仕様でタイプを「json」に設定します。たとえば、以下のようになります。"

#~ msgid "Note that AWS is unlikely to return the policy in the same order that is was submitted. Therefore, use the `compare_policies` helper function which handles this variance."
#~ msgstr "AWS が、送信された順序でポリシーを返すことはほとんどありません。したがって、この差異を処理する `compare_policies` ヘルパー関数を使用します。"

#~ msgid "`compare_policies` takes two dictionaries, recursively sorts and makes them hashable for comparison and returns True if they are different."
#~ msgstr "`compare_policies` は、2 つのディクショナリーを取得し、再帰的にソートし、比較のためにハッシュを可能にし、異なる場合は True を返します。"

#~ msgid "Dealing with tags"
#~ msgstr "タグの処理"

#~ msgid "AWS has a concept of resource tags. Usually the boto3 API has separate calls for tagging and untagging a resource.  For example, the ec2 API has a create_tags and delete_tags call."
#~ msgstr "AWS にはリソースタグの概念があります。通常、boto3 API には、リソースのタグ付けとタグ付け解除のための呼び出しがあります。たとえば、ec2 API には create_tags および delete_tags の呼び出しがあります。"

#~ msgid "It is common practice in Ansible AWS modules to have a `purge_tags` parameter that defaults to true."
#~ msgstr "これは、デフォルトが true の `purge_tags` パラメーターがある Ansible AWS モジュールでは一般的な方法です。"

#~ msgid "The `purge_tags` parameter means that existing tags will be deleted if they are not specified by the Ansible task."
#~ msgstr "`purge_tags` パラメーターは、既存のタグが Ansible タスクで指定されていない場合に削除されることを示しています。"

#~ msgid "There is a helper function `compare_aws_tags` to ease dealing with tags. It can compare two dicts and return the tags to set and the tags to delete.  See the Helper function section below for more detail."
#~ msgstr "タグの扱いを容易にするためヘルパー機能 `compare_aws_tags` があります。2 つのディクショナリーを比較し、設定するタグと削除するタグを返すことができます。詳細については、以下のヘルパー関数のセクションを参照してください。"

#~ msgid "Helper functions"
#~ msgstr "helper 関数"

#~ msgid "Along with the connection functions in Ansible ec2.py module_utils, there are some other useful functions detailed below."
#~ msgstr "Ansible ec2.py module_utils の接続関数に加えて、以下に説明するいくつかの便利な関数があります。"

#~ msgid "camel_dict_to_snake_dict"
#~ msgstr "camel_dict_to_snake_dict"

#~ msgid "boto3 returns results in a dict.  The keys of the dict are in CamelCase format. In keeping with Ansible format, this function will convert the keys to snake_case."
#~ msgstr "boto3 はディクショナリーの結果を返します。ディクショナリーのキーは CamelCase 形式になります。Ansible 形式を維持すると、この機能はキーを snake_case に変換します。"

#~ msgid "``camel_dict_to_snake_dict`` takes an optional parameter called ``ignore_list`` which is a list of keys not to convert (this is usually useful for the ``tags`` dict, whose child keys should remain with case preserved)"
#~ msgstr "``camel_dict_to_snake_dict`` は、``ignore_list`` 呼ばれる任意のパラメーターを取ります。これは、変換しないキーの一覧です。これは通常、``tags`` ディクショナリーに役に立ちます。この子キーは大文字と小文字を区別して保持する必要があります。"

#~ msgid "Another optional parameter is ``reversible``. By default, ``HTTPEndpoint`` is converted to ``http_endpoint``, which would then be converted by ``snake_dict_to_camel_dict`` to ``HttpEndpoint``. Passing ``reversible=True`` converts HTTPEndpoint to ``h_t_t_p_endpoint`` which converts back to ``HTTPEndpoint``."
#~ msgstr "その他の任意のパラメーターは ``reversible`` です。デフォルトでは、``HTTPEndpoint`` は ``http_endpoint`` に変換されます。これは、``snake_dict_to_camel_dict`` によって ``HttpEndpoint`` に変換されます。``reversible=True`` を渡すと、HTTPEndpoint が ``h_t_t_p_endpoint`` に変換され、``HTTPEndpoint`` に変換され直されます。"

#~ msgid "snake_dict_to_camel_dict"
#~ msgstr "snake_dict_to_camel_dict"

#~ msgid "`snake_dict_to_camel_dict` converts snake cased keys to camel case. By default, because it was first introduced for ECS purposes, this converts to dromedaryCase. An optional parameter called `capitalize_first`, which defaults to `False`, can be used to convert to CamelCase."
#~ msgstr "`snake_dict_to_camel_dict` は、スネークケースのキーをキャメルケースに変換します。デフォルトでは、ECS の目的で最初に導入されたため、これは dromedaryCase に変換されます。`capitalize_first` と呼ばれる任意のパラメーターは、`False` にデフォルトされ、CamelCase への変換に使用できます。"

#~ msgid "ansible_dict_to_boto3_filter_list"
#~ msgstr "ansible_dict_to_boto3_filter_list"

#~ msgid "Converts a an Ansible list of filters to a boto3 friendly list of dicts.  This is useful for any boto3 `_facts` modules."
#~ msgstr "フィルターの Ansible リストを、ディクショナリーの boto3 フレンドリーリストに変換します。これは、boto3 の `_facts` モジュールに役立ちます。"

#~ msgid "boto_exception"
#~ msgstr "boto_exception"

#~ msgid "Pass an exception returned from boto or boto3, and this function will consistently get the message from the exception."
#~ msgstr "boto または boto3 から返された例外を渡します。この関数は、例外からメッセージを一貫して取得します。"

#~ msgid "Deprecated: use `AnsibleAWSModule`'s `fail_json_aws` instead."
#~ msgstr "非推奨: 代わりに `AnsibleAWSModule` の `fail_json_aws` を使用してください。"

#~ msgid "boto3_tag_list_to_ansible_dict"
#~ msgstr "boto3_tag_list_to_ansible_dict"

#~ msgid "Converts a boto3 tag list to an Ansible dict. Boto3 returns tags as a list of dicts containing keys called 'Key' and 'Value' by default.  This key names can be overridden when calling the function. For example, if you have already camel_cased your list of tags you may want to pass lowercase key names instead, in other words, 'key' and 'value'."
#~ msgstr "boto3 タグリストを Ansible ディクショナリーに変換します。Boto3 は、「Key」および「Value」という名前のキーがデフォルトで含まれる ディクショナリーのリストとしてタグを返します。このキーは、関数を呼び出す際に上書きできます。たとえば、タグのリストをすでにキャメルケース化している場合は、代わりに小文字のキー名、つまり「key」と「value」を渡すことができます。"

#~ msgid "This function converts the list in to a single dict where the dict key is the tag key and the dict value is the tag value."
#~ msgstr "この関数は、リストを単一のディクショナリーに変換します。dict キーはタグキーで、dict 値はタグの値です。"

#~ msgid "ansible_dict_to_boto3_tag_list"
#~ msgstr "ansible_dict_to_boto3_tag_list"

#~ msgid "Opposite of above. Converts an Ansible dict to a boto3 tag list of dicts. You can again override the key names used if 'Key' and 'Value' is not suitable."
#~ msgstr "上記の逆で、Ansible ディクショナリーをディクショナリーの boto3 タグ一覧に変換します。「Key」と「Value」が適していないときに使用されるキー名を再度上書きすることもできます。"

#~ msgid "get_ec2_security_group_ids_from_names"
#~ msgstr "get_ec2_security_group_ids_from_names"

#~ msgid "Pass this function a list of security group names or combination of security group names and IDs and this function will return a list of IDs.  You should also pass the VPC ID if known because security group names are not necessarily unique across VPCs."
#~ msgstr "この関数にセキュリティーグループ名のリスト、またはセキュリティーグループ名とIDの組み合わせを渡すと、この関数は ID のリストを返します。セキュリティーグループ名は VPC 間で必ずしも一意であるとは限らないため、既知の場合は VPCID も渡す必要があります。"

#~ msgid "compare_policies"
#~ msgstr "compare_policies"

#~ msgid "Pass two dicts of policies to check if there are any meaningful differences and returns true if there are. This recursively sorts the dicts and makes them hashable before comparison."
#~ msgstr "ポリシーの 2 つのディクショナリーを渡して、意味のある差異があるかどうかを確認し、ある場合は true を返します。これにより、ディクショナリーが再帰的にソートされ、比較前にハッシュ可能になります。"

#~ msgid "This method should be used any time policies are being compared so that a change in order doesn't result in unnecessary changes."
#~ msgstr "この方法は、順序を変更しても不要な変更が発生しないように、ポリシーを比較するときに必ず使用する必要があります。"

#~ msgid "compare_aws_tags"
#~ msgstr "compare_aws_tags"

#~ msgid "Pass two dicts of tags and an optional purge parameter and this function will return a dict containing key pairs you need to modify and a list of tag key names that you need to remove.  Purge is True by default.  If purge is False then any existing tags will not be modified."
#~ msgstr "タグの 2 つのディクショナリーと任意の purge パラメーターを渡します。この関数はディクショナリーを返します。これには、変更するキーペアと、削除する必要のあるタグキー名の一覧が含まれています。パージは、デフォルトで True です。パージが False の場合は、既存のタグが変更されません。"

#~ msgid "This function is useful when using boto3 'add_tags' and 'remove_tags' functions. Be sure to use the other helper function `boto3_tag_list_to_ansible_dict` to get an appropriate tag dict before calling this function. Since the AWS APIs are not uniform (for example, EC2 is different from Lambda) this will work without modification for some (Lambda) and others may need modification before using these values (such as EC2, with requires the tags to unset to be in the form `[{'Key': key1}, {'Key': key2}]`)."
#~ msgstr "この関数は、boto3 の「add_tags」関数および「remove_tags」関数を使用する場合に役に立ちます。この関数を呼び出す前に、必ず他のヘルパー関数 `boto3_tag_list_to_ansible_dict` を使用して、適切なタグのディクショナリーを取得してください。AWS の API は統一されていないため (たとえば、EC2 と Lambda は異なる)、一部 (Lambda) では修正なしで動作しますが、他ではこれらの値を使用する前に修正が必要な場合があります(EC2 では、設定解除するタグを `[{'Key': key1}, {'Key': key2}]` の形式にする必要があるなど)。"

#~ msgid "Integration Tests for AWS Modules"
#~ msgstr "AWS モジュールの統合テスト"

#~ msgid "All new AWS modules should include integration tests to ensure that any changes in AWS APIs that affect the module are detected. At a minimum this should cover the key API calls and check the documented return values are present in the module result."
#~ msgstr "すべての新規 AWS モジュールには、モジュールに影響する AWS API の変更が検出されるように、統合テストを含める必要があります。最小値はキー API 呼び出しに対応し、文書化された戻り値がモジュールの結果に存在するようにする必要があります。"

#~ msgid "For general information on running the integration tests see the :ref:`Integration Tests page of the Module Development Guide <testing_integration>`, especially the section on configuration for cloud tests."
#~ msgstr "統合テストの実行に関する一般的な情報は、:ref:`モジュール開発ガイドの統合テストページ <testing_integration>` ページ (特に、クラウドテスト設定のセクション) を参照してください。"

#~ msgid "The integration tests for your module should be added in `test/integration/targets/MODULE_NAME`."
#~ msgstr "モジュールの統合テストは、`test/integration/targets/MODULE_NAME` に追加する必要があります。"

#~ msgid "You must also have a aliases file in `test/integration/targets/MODULE_NAME/aliases`. This file serves two purposes. First indicates it's in an AWS test causing the test framework to make AWS credentials available during the test run. Second putting the test in a test group causing it to be run in the continuous integration build."
#~ msgstr "また、`test/integration/targets/MODULE_NAME/aliases` にはエイリアスファイルが必要です。このファイルには 2 つの目的があります。最初に、それが AWS テストにあり、テストフレームワークがテスト実行中に AWS 認証情報を利用できるようにしていることを示します。次に、テストをテストグループに入れて、継続的インテグレーションビルドで実行します。"

#~ msgid "Tests for new modules should be added to the same group as existing AWS tests. In general just copy an existing aliases file such as the `aws_s3 tests aliases file <https://github.com/ansible-collections/amazon.aws/blob/master/tests/integration/targets/aws_s3/aliases>`_."
#~ msgstr "新規モジュールのテストは、既存の AWS テストと同じグループに追加する必要があります。一般に、`aws_s3 テストエイリアスファイル <https://github.com/ansible-collections/amazon.aws/blob/master/tests/integration/targets/aws_s3/aliases>`_ のような既存のエイリアスファイルをコピーするだけです。"

#~ msgid "AWS Credentials for Integration Tests"
#~ msgstr "統合テストの AWS 認証情報"

#~ msgid "The testing framework handles running the test with appropriate AWS credentials, these are made available to your test in the following variables:"
#~ msgstr "テストフレームワークは、適切な AWS 認証情報を使用したテストの実行を処理します。この認証情報は、次の変数で、テストに利用できます。"

#~ msgid "`aws_region`"
#~ msgstr "`aws_region`"

#~ msgid "`aws_access_key`"
#~ msgstr "`aws_access_key`"

#~ msgid "`aws_secret_key`"
#~ msgstr "`aws_secret_key`"

#~ msgid "`security_token`"
#~ msgstr "`security_token`"

#~ msgid "So all invocations of AWS modules in the test should set these parameters. To avoid duplicating these for every call, it's preferable to use :ref:`module_defaults <module_defaults>`. For example:"
#~ msgstr "したがって、テストで AWS モジュールを呼び出す場合はすべて、これらのパラメーターを設定する必要があります。呼び出しごとにこれらが重複しないようにするには、:ref:`module_defaults <module_defaults>` を使用することが推奨されます。以下に例を示します。"

#~ msgid "AWS Permissions for Integration Tests"
#~ msgstr "統合テスト用の AWS パーミッション"

#~ msgid "As explained in the :ref:`Integration Test guide <testing_integration>` there are defined IAM policies in `mattclay/aws-terminator <https://github.com/mattclay/aws-terminator>`_ that contain the necessary permissions to run the AWS integration test."
#~ msgstr ":ref:`Integration Test guide <testing_integration>` で説明されているように、AWS 統合テストを実行するために必要な権限が含まれる `mattclay/aws-terminator <https://github.com/mattclay/aws-terminator>`_ で定義された IAM ポリシーがあります。"

#~ msgid "If your module interacts with a new service or otherwise requires new permissions, tests will fail when you submit a pull request and the `Ansibullbot <https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md>`_ will tag your PR as needing revision. We do not automatically grant additional permissions to the roles used by the continuous integration builds. You will need to raise a Pull Request against `mattclay/aws-terminator <https://github.com/mattclay/aws-terminator>`_ to add them."
#~ msgstr "モジュールが新しいサービスとやり取りする場合、または別の方法で新しいパーミッションが必要な場合は、プル要求を送信すると、テストは失敗します。`Ansibullbot <https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md>`_ は、PR に修正が必要なタグを付けます。継続的インテグレーションビルドで使用されるロールに追加のパーミッションを自動的に付与することはありません。それを追加するには、`mattclay/aws-terminator <https://github.com/mattclay/aws-terminator>`_ に対してプル要求を発行する必要があります、それらを追加します。"

#~ msgid "If your PR has test failures, check carefully to be certain the failure is only due to the missing permissions. If you've ruled out other sources of failure, add a comment with the `ready_for_review` tag and explain that it's due to missing permissions."
#~ msgstr "PR にテストの失敗がある場合は、失敗の原因がパーミッションの欠落のみであることをしっかりと確認してください。他の失敗の原因を除外した場合は、`ready_for_review` タグを使用してコメントを追加して、権限がないことが原因であることを説明します。"

#~ msgid "Your pull request cannot be merged until the tests are passing. If your pull request is failing due to missing permissions, you must collect the minimum IAM permissions required to run the tests."
#~ msgstr "テストに合格するまでプル要求がマージできません。パーミッションがないためにプル要求が失敗すると、テストの実行に必要な最低限の IAM パーミッションを収集する必要があります。"

#~ msgid "There are two ways to figure out which IAM permissions you need for your PR to pass:"
#~ msgstr "PR に合格するために必要な IAM パーミッションを確認する場合は、以下の 2 つの方法があります。"

#~ msgid "Start with the most permissive IAM policy, run the tests to collect information about which resources your tests actually use, then construct a policy based on that output. This approach only works on modules that use `AnsibleAWSModule`."
#~ msgstr "最も許容度の高い IAM ポリシーから始めて、テストを実行し、テストが実際に使用するリソースに関する情報を収集し、その出力に基づいてポリシーを構築します。このアプローチは、`AnsibleAWSModule` を使用するモジュールでのみ機能します。"

#~ msgid "Start with the least permissive IAM policy, run the tests to discover a failure, add permissions for the resource that addresses that failure, then repeat. If your module uses `AnsibleModule` instead of `AnsibleAWSModule`, you must use this approach."
#~ msgstr "最も許容度の低い IAM ポリシーから開始し、テストを実行して障害を検出し、その障害に対処するリソースのパーミッションを追加してから、繰り返します。モジュールが使用する場合は、`AnsibleAWSModule` の代わりに `AnsibleModule` を使用する場合は、このアプローチを使用する必要があります。"

#~ msgid "To start with the most permissive IAM policy:"
#~ msgstr "最も許容度の高い IAM ポリシーを使用するには、以下を実行します。"

#~ msgid "`Create an IAM policy <https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start>`_ that allows all actions (set ``Action`` and ``Resource`` to ``*```)."
#~ msgstr "すべてのアクションを許可する `IAM ポリシーを作成 <https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start>`_ します (``Action`` および ``Resource`` を ``*``' に設定)。"

#~ msgid "Run your tests locally with this policy. On AnsibleAWSModule-based modules, the ``debug_botocore_endpoint_logs`` option is automatically set to ``yes``, so you should see a list of AWS ACTIONS after the PLAY RECAP showing all the permissions used. If your tests use a boto/AnsibleModule module, you must start with the least permissive policy (see below)."
#~ msgstr "このポリシーを使用して、ローカルでテストを実行します。AnsibleAWSModule ベースのモジュールでは、``debug_botocore_endpoint_logs`` オプションが自動的に ``yes`` に設定されます。したがって、PLAY RECAP の後に、使用されているすべてのパーミッションを示す AWSACTIONS のリストが表示されます。テストで boto/AnsibleModule モジュールを使用する場合は、最も許容度の低いポリシーから開始する必要があります (以下を参照)。"

#~ msgid "Modify your policy to allow only the actions your tests use. Restrict account, region, and prefix where possible. Wait a few minutes for your policy to update."
#~ msgstr "テストで使用するアクションのみを許可するようにポリシーを変更します。可能な場合は、アカウント、地域、プレフィックスを制限してください。ポリシーが更新されるまで数分待ちます。"

#~ msgid "Run the tests again with a user or role that allows only the new policy."
#~ msgstr "新規ポリシーのみを許可するユーザーまたはロールでテストを再実行します。"

#~ msgid "If the tests fail, troubleshoot (see tips below), modify the policy, run the tests again, and repeat the process until the tests pass with a restrictive policy."
#~ msgstr "テストに失敗し、トラブルシューティング (以下のヒントを参照) を行い、ポリシーを変更し、テストを再実行し、制限的なポリシーでテストに合格するまでプロセスを繰り返します。"

#~ msgid "Open a pull request proposing the minimum required policy to the `CI policies <https://github.com/mattclay/aws-terminator/tree/master/aws/policy>`_."
#~ msgstr "`CI policies <https://github.com/mattclay/aws-terminator/tree/master/aws/policy>`_ に対して最低限必要なポリシーを提案するプル要求を開きます。"

#~ msgid "To start from the least permissive IAM policy:"
#~ msgstr "最も許容度の低い IAM ポリシーから開始するには、以下を実行します。"

#~ msgid "Run the integration tests locally with no IAM permissions."
#~ msgstr "IAM パーミッションを持たないローカルの統合テストを実行します。"

#~ msgid "Examine the error when the tests reach a failure."
#~ msgstr "テストが失敗した場合はエラーを確認します。"

#~ msgid "If the error message indicates the action used in the request, add the action to your policy."
#~ msgstr "エラーメッセージがリクエストで使用されるアクションを示す場合は、アクションをポリシーに追加します。"

#~ msgid "If the error message does not indicate the action used in the request:"
#~ msgstr "エラーメッセージがリクエストで使用されるアクションを示していない場合は、以下を行います。"

#~ msgid "Usually the action is a CamelCase version of the method name - for example, for an ec2 client the method `describe_security_groups` correlates to the action `ec2:DescribeSecurityGroups`."
#~ msgstr "通常、アクションはメソッド名の CamelCase バージョンです。たとえば、ec2 クライアントの場合、`describe_security_groups` メソッドはアクション `ec2:DescribeSecurityGroups` に相関します。"

#~ msgid "Refer to the documentation to identify the action."
#~ msgstr "アクションを特定するには、ドキュメントを参照してください。"

#~ msgid "If the error message indicates the resource ARN used in the request, limit the action to that resource."
#~ msgstr "エラーメッセージが要求で使用されるリソース ARN を示す場合は、アクションをそのリソースに制限します。"

#~ msgid "If the error message does not indicate the resource ARN used:"
#~ msgstr "エラーメッセージに、使用されたリソース ARN が示されない場合は、以下を行います。"

#~ msgid "Determine if the action can be restricted to a resource by examining the documentation."
#~ msgstr "ドキュメントを参照して、アクションをリソースに制限できるかどうかを判断します。"

#~ msgid "If the action can be restricted, use the documentation to construct the ARN and add it to the policy."
#~ msgstr "アクションが制限されている場合は、ドキュメントを使用して ARN を構築し、ポリシーに追加します。"

#~ msgid "Add the action or resource that caused the failure to `an IAM policy <https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start>`_. Wait a few minutes for your policy to update."
#~ msgstr "`IAM ポリシー <https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start>`_ の失敗の原因となったアクションまたはリソースを追加します。ポリシーが更新まで数分待ちます。"

#~ msgid "Run the tests again with this policy attached to your user or role."
#~ msgstr "ユーザーまたはロールにこのポリシーを割り当てテストを再実行します。"

#~ msgid "If the tests still fail at the same place with the same error you will need to troubleshoot (see tips below). If the first test passes, repeat steps 2 and 3 for the next error. Repeat the process until the tests pass with a restrictive policy."
#~ msgstr "それでも同じ場所で同じエラーでテストが失敗する場合はは、トラブルシューティングを行う必要があります (以下のヒントを参照)。最初のテストに合格した場合は、次のエラーに対して手順 2 と 3 を繰り返します。制限付きポリシーでテストに合格するまで、このプロセスを繰り返します。"

#~ msgid "Troubleshooting IAM policies"
#~ msgstr "IAM ポリシーのトラブルシューティング"

#~ msgid "When you make changes to a policy, wait a few minutes for the policy to update before re-running the tests."
#~ msgstr "ポリシーに変更を加えたら、ポリシーが更新されるまで数分待ってからテストを再実行します。"

#~ msgid "Use the `policy simulator <https://policysim.aws.amazon.com/>`_ to verify that each action (limited by resource when applicable) in your policy is allowed."
#~ msgstr "`ポリシーシミュレーター <https://policysim.aws.amazon.com/>`_ を使用して、ポリシー内の (該当する場合はリソースによって制限されている) が許可されていることを確認します。"

#~ msgid "If you're restricting actions to certain resources, replace resources temporarily with `*`. If the tests pass with wildcard resources, there is a problem with the resource definition in your policy."
#~ msgstr "特定のリソースにアクションを制限する場合は、リソースを一時的に `*` に置き換えます。ワイルドカードリソースでテストに合格した場合は、ポリシーのリソース定義に問題があります。"

#~ msgid "If the initial troubleshooting above doesn't provide any more insight, AWS may be using additional undisclosed resources and actions."
#~ msgstr "上記の最初のトラブルシューティングでより多くの洞察が得られない場合、AWS は追加の未公開のリソースおよびアクションを使用している可能性があります。"

#~ msgid "Examine the AWS FullAccess policy for the service for clues."
#~ msgstr "手がかりについては、サービスの AWS FullAccess ポリシーを調べます。"

#~ msgid "Re-read the AWS documentation, especially the list of `Actions, Resources and Condition Keys <https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html>`_ for the various AWS services."
#~ msgstr "各種の AWS サービスの `Actions, Resources and Condition Keys <https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html>`_ の一覧など、AWS ドキュメントを再度読みます。"

#~ msgid "Look at the `cloudonaut <https://iam.cloudonaut.io>`_ documentation as a troubleshooting cross-reference."
#~ msgstr "トラブルシューティングの相互参照として `cloudonaut <https://iam.cloudonaut.io>`_ ドキュメントをご覧ください。"

#~ msgid "Use a search engine."
#~ msgstr "検索エンジンを使用します。"

#~ msgid "Ask in the Ansible IRC channel #ansible-aws (on freenode IRC)."
#~ msgstr "Freenode IRC の Ansible IRC チャンネル #ansible-aws に問い合わせます。"

#~ msgid "Unsupported Integration tests"
#~ msgstr "サポートされないインテグレーションのテスト"

#~ msgid "There are a limited number of reasons why it may not be practical to run integration tests for a module within CI.  Where these apply you should add the keyword `unsupported` to the aliases file in `test/integration/targets/MODULE_NAME/aliases`."
#~ msgstr "CI 内のモジュールの統合テストを実行する場合には、いくつかの理由が限定されている理由があります。これらの理由については、キーワード `unsupported` を `test/integration/targets/MODULE_NAME/aliases` のエイリアスファイルに追加する必要があります。"

#~ msgid "Some cases where tests should be marked as unsupported: 1) The tests take longer than 10 or 15 minutes to complete 2) The tests create expensive resources 3) The tests create inline policies 4) The tests require the existence of external resources 5) The tests manage Account level security policies such as the password policy or AWS Organizations."
#~ msgstr "テストがサポート対象外としてマークされる必要がある場合があります。1) テストが完了するまで 10 分または 15 分以上かかります。2) テストにより、高価なリソースが作成されます。3) テストにより、インラインポリシーが作成されます。4) テストに外部リソースの存在が必要になります。5) テストは、パスワードポリシーや AWS 組織などのアカウントレベルのセキュリティポリシーを管理します。"

#~ msgid "Where one of these reasons apply you should open a pull request proposing the minimum required policy to the `unsupported test policies <https://github.com/mattclay/aws-terminator/tree/master/hacking/aws_config/test_policies>`_."
#~ msgstr "上記の理由の 1 つは、`サポートされないテストポリシー <https://github.com/mattclay/aws-terminator/tree/master/hacking/aws_config/test_policies>`_ に対して最低限必要なポリシーを提案するプル要求を開きます。"

#~ msgid "Unsupported integration tests will not be automatically run by CI.  However, the necessary policies should be available so that the tests can be manually run by someone performing a PR review or writing a patch."
#~ msgstr "サポート対象外の統合テストは CI によって自動的に実行されませんが、必要なポリシーを利用すると、PR レビューまたはパッチの作成を実行してテストを手動で実行できるようにする必要があります。"

#~ msgid "The set of modules for interacting with oVirt/RHV are currently part of the community.general collection (on `Galaxy <https://galaxy.ansible.com/community/general>`_, source code `repository <https://github.com/ansible-collections/community.general/tree/main/plugins/modules/cloud/ovirt>`_). This document serves as developer coding guidelines for creating oVirt/RHV modules."
#~ msgstr "oVirt/RHV との対話に使用するモジュールセットは、現在 community.general コレクション (`Galaxy <https://galaxy.ansible.com/community/general>`_ ではソースコード `repository <https://github.com/ansible-collections/community.general/tree/main/plugins/modules/cloud/ovirt>`_) に含まれます。このドキュメントは、oVirt/RHV モジュールを作成するための開発者コーディングのガイドラインとして機能します。"

#~ msgid "All modules should start with an ``ovirt_`` prefix."
#~ msgstr "すべてのモジュールは、``ovirt_`` 接頭辞で開始する必要があります。"

#~ msgid "All modules should be named after the resource it manages in singular form."
#~ msgstr "すべてのモジュールは、管理するリソースにちなんで単数形で名前を付ける必要があります。"

#~ msgid "All modules that gather information should have a ``_info`` suffix."
#~ msgstr "情報を収集するすべてのモジュールには、``_info`` 構文があります。"

#~ msgid "Interface"
#~ msgstr "インターフェース"

#~ msgid "Every module should return the ID of the resource it manages."
#~ msgstr "すべてのモジュールは、管理するリソースの ID を返す必要があります。"

#~ msgid "Every module should return the dictionary of the resource it manages."
#~ msgstr "すべてのモジュールは、管理するリソースのディレクトリーを返す必要があります。"

#~ msgid "Never change the name of the parameter, as we guarantee backward compatibility. Use aliases instead."
#~ msgstr "後方互換性を保証するため、パラメーターの名前は変更しないでください。代わりにエイリアスを使用してください。"

#~ msgid "If a parameter can't achieve idempotency for any reason, please document it."
#~ msgstr "パラメーターが何らかの理由で冪等性を実現できない場合は、それを文書化してください。"

#~ msgid "Interoperability"
#~ msgstr "相互運用性"

#~ msgid "All modules should work against all minor versions of version 4 of the API. Version 3 of the API is not supported."
#~ msgstr "すべてのモジュールは API のバージョン 4 のすべてのマイナーバージョンに対して動作します。API のバージョン 3 はサポート対象外です。"

#~ msgid "Libraries"
#~ msgstr "ライブラリー"

#~ msgid "All modules should use ``ovirt_full_argument_spec`` or ``ovirt_info_full_argument_spec`` to pick up the standard input (such as auth and ``fetch_nested``)."
#~ msgstr "すべてのモジュールは ``ovirt_full_argument_spec`` または ``ovirt_info_full_argument_spec`` を使用して、標準入力 (認証、``fetch_nested`` など) にする必要があります。"

#~ msgid "All modules should use ``extends_documentation_fragment``: ovirt to go along with ``ovirt_full_argument_spec``."
#~ msgstr "すべてのモジュールは、``ovirt_full_argument_spec`` に従うために ``extends_documentation_fragment``: ovirt を使用する必要があります。"

#~ msgid "All info modules should use ``extends_documentation_fragment``: ``ovirt_info`` to go along with ``ovirt_info_full_argument_spec``."
#~ msgstr "すべての info モジュールは、``ovirt_info_full_argument_spec`` に従うために ``extends_documentation_fragment``: ``ovirt_info`` を使用する必要があります。"

#~ msgid "Functions that are common to all modules should be implemented in the ``module_utils/ovirt.py`` file, so they can be reused."
#~ msgstr "すべてのモジュールに共通する関数は、``module_utils/ovirt.py`` ファイルに実装されているため、再利用できます。"

#~ msgid "Python SDK version 4 must be used."
#~ msgstr "Python SDK バージョン 4 を使用する必要があります。"

#~ msgid "New module development"
#~ msgstr "新しいモジュール開発"

#~ msgid "Please read :ref:`developing_modules`, first to know what common properties, functions and features every module must have."
#~ msgstr "「:ref:`developing_modules`」をお読みください。最初に、すべてのモジュールに必要な共通のプロパティー、関数、および機能を確認します。"

#~ msgid "In order to achieve idempotency of oVirt entity attributes, a helper class was created. The first thing you need to do is to extend this class and override a few methods:"
#~ msgstr "oVirt エンティティー属性のべき等性を実現するには、ヘルパークラスが作成されました。まず、このクラスを拡張し、いくつかのメソッドを上書きする必要があります。"

#~ msgid "The code above handle the check if the entity should be updated, so we don't update the entity if not needed and also it construct the needed entity of the SDK."
#~ msgstr "上記のコードは、エンティティーを更新すべきかどうかのチェックを処理するため、必要でない場合はエンティティーを更新せず、SDK に必要なエンティティーを構築します。"

#~ msgid "If your module must support action handling (for example, virtual machine start) you must ensure that you handle the states of the virtual machine correctly, and document the behavior of the module:"
#~ msgstr "モジュールがアクション処理 (例: 仮想マシンの開始) をサポートする必要がある場合は、仮想マシンの状態を正しく処理し、モジュールの動作を文書化する必要があります。"

#~ msgid "As you can see from the preceding example, the ``action`` method accepts the ``action_condition`` and ``wait_condition``, which are methods which accept the virtual machine object as a parameter, so you can check whether the virtual machine is in a proper state before the action. The rest of the parameters are for the ``start`` action. You may also handle pre- or post- action tasks by defining ``pre_action`` and ``post_action`` parameters."
#~ msgstr "前述の例で分かるように、``action`` メソッドは ``action_condition`` および ``wait_condition`` (仮想マシンオブジェクトをパラメーターとして許可するメソッド) を受け入れます。そのため、仮想マシンがアクションの前に適切な状態にあるかどうかを確認できます。残りのパラメーターは ``start`` アクション用です。``pre_action`` パラメーターおよび ``post_action`` パラメーターを定義して、事前または後続のアクションのタスクを処理することもできます。"

#~ msgid "Testing"
#~ msgstr "テスト"

#~ msgid "Integration testing is currently done in oVirt's CI system `on Jenkins <https://jenkins.ovirt.org/view/All/job/ovirt-system-tests_ansible-suite-master/>`__ and `on GitHub <https://github.com/oVirt/ovirt-system-tests/tree/master/ansible-suite-master/>`__."
#~ msgstr "統合テストは、現在、__ と `GitHub <https://github.com/oVirt/ovirt-system-tests/tree/master/ansible-suite-master/>`__ の oVirt's CI システム で行われています。"

#~ msgid "Please consider using these integration tests if you create a new module or add a new feature to an existing module."
#~ msgstr "新しいモジュールを作成する場合、または既存のモジュールに新しい機能を追加する場合は、これらの統合テストの使用を検討してください。"

#~ msgid "The Ansible VMware collection (on `Galaxy <https://galaxy.ansible.com/community/vmware>`_, source code `repository <https://github.com/ansible-collections/community.vmware>`_) is maintained by the VMware Working Group. For more information see the `team community page <https://github.com/ansible/community/wiki/VMware>`_."
#~ msgstr "詳細は、Ansible VMware コレクション (`Galaxy <https://galaxy.ansible.com/community/vmware>`_ で、ソースコード `repository <https://github.com/ansible-collections/community.vmware>`_) は VMware ワーキンググループにより維持されます。詳細は `team community page <https://github.com/ansible/community/wiki/VMware>`_ を参照してください。"

#~ msgid "Testing with govcsim"
#~ msgstr "govcsim を使用したテスト"

#~ msgid "Most of the existing modules are covered by functional tests. The tests are located `here <https://github.com/ansible-collections/community.vmware/tree/main/tests/integration/targets>`_."
#~ msgstr "既存のモジュールのほとんどは、機能テストで対応しています。テストは、`ここ <https://github.com/ansible-collections/community.vmware/tree/main/tests/integration/targets>`_ に置かれます。"

#~ msgid "By default, the tests run against a vCenter API simulator called `govcsim <https://github.com/vmware/govmomi/tree/master/vcsim>`_. ``ansible-test`` will automatically pull a `govcsim container <https://quay.io/repository/ansible/vcenter-test-container>`_ and use it to set-up the test environment."
#~ msgstr "デフォルトでは、テストは、`govcsim <https://github.com/vmware/govmomi/tree/master/vcsim>`_ という名前の vCenter API シミュレーターに対して実行されます。``ansible-test`` は、`govcsim コンテナー <https://quay.io/repository/ansible/vcenter-test-container>`_ を自動的にプルし、これを使用してテスト環境を設定します。"

#~ msgid "You can trigger the test of a module manually with the ``ansible-test`` command. For example, to trigger ``vcenter_folder`` tests:"
#~ msgstr "``ansible-test`` コマンドを使用して、モジュールのテストを手動でトリガーできます。たとえば、``vcenter_folder`` テストを開始するには、以下を行います。"

#~ msgid "``govcsim`` is handy because it is much faster than a regular test environment. However, ``govcsim`` does not support all the ESXi or vCenter features."
#~ msgstr "``govcsim`` は、通常のテスト環境よりもはるかに高速ですが、``govcsim`` は ESXi 機能または vCenter 機能をすべてサポートしません。"

#~ msgid "Do not confuse ``govcsim`` with ``vcsim``. ``vcsim`` is an older and outdated version of vCenter simulator, whereas ``govcsim`` is new and written in Go language."
#~ msgstr "``govcsim`` と ``vcsim`` を混同しないでください。``vcsim`` は、古いバージョンの vCenterシミュレーターですが、``govcsim`` は新しく、Go 言語で書かれています"

#~ msgid "Testing with your own infrastructure"
#~ msgstr "独自のインフラストラクチャーでのテスト"

#~ msgid "You can also target a regular VMware environment. This paragraph explains step by step how you can run the test-suite yourself."
#~ msgstr "通常の VMware 環境を対象とすることもできます。この段落では、テストスイートを自分で実行する方法について順を追って説明します。"

#~ msgid "2 ESXi hosts (6.5 or 6.7)"
#~ msgstr "2 台の ESXi ホスト (6.5 または 6.7)"

#~ msgid "with 2 NIC, the second ones should be available for the test"
#~ msgstr "2 つの NIC (テスト用に 2 番目の NIC が利用可能)"

#~ msgid "a VCSA host"
#~ msgstr "VCSA ホスト"

#~ msgid "a NFS server"
#~ msgstr "NFS サーバー"

#~ msgid "Python dependencies:"
#~ msgstr "Python の依存関係:"

#~ msgid "`pyvmomi <https://github.com/vmware/pyvmomi/tree/master/pyVmomi>`_"
#~ msgstr "`pyvmomi <https://github.com/vmware/pyvmomi/tree/master/pyVmomi>`_"

#~ msgid "`requests <https://2.python-requests.org/en/master/>`_"
#~ msgstr "`requests <https://2.python-requests.org/en/master/>`_"

#~ msgid "If you want to deploy your test environment in a hypervisor, both `VMware or Libvirt <https://github.com/goneri/vmware-on-libvirt>`_ works well."
#~ msgstr "ハイパーバイザーにテスト環境をデプロイする場合は、`VMware または Libvirt <https://github.com/goneri/vmware-on-libvirt>` の両方が正常に機能します。"

#~ msgid "NFS server configuration"
#~ msgstr "NFS サーバーの設定"

#~ msgid "Your NFS server must expose the following directory structure:"
#~ msgstr "NFS サーバーでは、以下のディレクトリー構造を公開する必要があります。"

#~ msgid "On a Linux system, you can expose the directory over NFS with the following export file:"
#~ msgstr "Linux システムでは、次のエクスポートファイルを使用して、NFS 経由でディレクトリーを公開できます。"

#~ msgid "With this configuration all the new files will be owned by the user with the UID and GID 1000/1000. Adjust the configuration to match your user's UID/GID."
#~ msgstr "この設定では、UID 1000 および GID 1000 のユーザーが、新しいファイルをすべて所有します。ユーザーの UID および GID に合わせて設定を調整してください。"

#~ msgid "The service can be enabled with:"
#~ msgstr "このサービスは以下で有効にできます。"

#~ msgid "Configure your installation"
#~ msgstr "インストールの設定"

#~ msgid "Prepare a configuration file that describes your set-up. The file should be called :file:`test/integration/cloud-config-vcenter.ini` and based on :file:`test/lib/ansible_test/config/cloud-config-vcenter.ini.template`. For instance, if you have deployed your lab with `vmware-on-libvirt <https://github.com/goneri/vmware-on-libvirt>`_:"
#~ msgstr "セットアップを説明する構成ファイルを準備します。このファイルは :file:`test/integration/cloud-config-vcenter.ini` という名前し、:file:`test/lib/ansible_test/config/cloud-config-vcenter.ini.template` をベースにする必要があります。たとえば、`vmware-on-libvirt <https://github.com/goneri/vmware-on-libvirt>`_ でラボをデプロイした場合は以下のようになります。"

#~ msgid "Using an HTTP proxy"
#~ msgstr "HTTP プロキシーの使用"

#~ msgid "Hosting test infrastructure behind an HTTP proxy is supported. You can specify the location of the proxy server with the two extra keys:"
#~ msgstr "HTTP プロキシーの背後にあるホスティングテストインフラストラクチャーがサポートされています。次の 2 つの追加キーを使用して、プロキシーサーバーの場所を指定できます。"

#~ msgid "In addition, you may need to adjust the variables of the following `var files <https://github.com/ansible-collections/community.vmware/tree/main/tests/integration/targets/prepare_vmware_tests/vars>`_ to match the configuration of your lab. If you use vmware-on-libvirt to prepare your lab, you do not have anything to change."
#~ msgstr "さらに、ラボの構成に一致させるために、次の `var ファイル <https://github.com/ansible-collections/community.vmware/tree/main/tests/integration/targets/prepare_vmware_tests/vars>`_ の変数を調整しないといけない場合があります。vmware-on-libvirt を使用してラボを準備する場合は、変更することができません。"

#~ msgid "Run the test-suite"
#~ msgstr "テストスイートの実行"

#~ msgid "Once your configuration is ready, you can trigger a run with the following command:"
#~ msgstr "設定の準備ができたら、以下のコマンドで実行をトリガーできます。"

#~ msgid "``vmware_host_firewall_manager`` is the name of the module to test."
#~ msgstr "``vmware_host_firewall_manager`` は、テストするモジュールの名前です。"

#~ msgid "``vmware_guest`` is much larger than any other test role and is rather slow. You can enable or disable some of its test playbooks in `main.yml <https://github.com/ansible-collections/community.vmware/tree/main/tests/integration/targets/vmware_guest/defaults/main.yml>`_."
#~ msgstr "``vmware_guest`` は、他のテストロールよりもはるかに大きく、速度もかなり遅くなります。`main.yml <https://github.com/ansible-collections/community.vmware/tree/main/tests/integration/targets/vmware_guest/defaults/main.yml>`_ でテスト Playbook の一部を有効または無効にできます。"

#~ msgid "Unit-test"
#~ msgstr "ユニットテスト"

#~ msgid "The VMware modules have limited unit-test coverage. You can run the test suite with the following commands:"
#~ msgstr "VMware モジュールには、unit-test の範囲が限定されています。以下のコマンドを実行してテストスイートを実行できます。"

#~ msgid "Code style and best practice"
#~ msgstr "コードスタイルおよびベストプラクティス"

#~ msgid "datacenter argument with ESXi"
#~ msgstr "ESXi での datacenter 引数"

#~ msgid "The ``datacenter`` parameter should not use ``ha-datacenter`` by default. This is because the user may not realize that Ansible silently targets the wrong data center."
#~ msgstr "``datacenter`` パラメーターはデフォルトで ``ha-datacenter`` を使用しないでください。これは、Ansible が間違ったデータセンターをサイレントにターゲットにしていることにユーザーが気付かない可能性があるためです。"

#~ msgid "esxi_hostname should not be mandatory"
#~ msgstr "esxi_hostname は必須ではない"

#~ msgid "Depending upon the functionality provided by ESXi or vCenter, some modules can seamlessly work with both. In this case, ``esxi_hostname`` parameter should be optional."
#~ msgstr "ESXi または vCenter が提供する機能に応じて、一部のモジュールは両方でシームレスに動作します。この場合、``esxi_hostname`` パラメーターは任意である必要があります。"

#~ msgid "Example should use the fully qualified collection name (FQCN)"
#~ msgstr "例では、完全修飾コレクション名 (FQCN) を使用する必要があります"

#~ msgid "Use FQCN for examples within module documentation. For instance, you should use ``community.vmware.vmware_guest`` instead of just ``vmware_guest``."
#~ msgstr "モジュールドキュメントの例としては、FQCN を使用してください。たとえば、``vmware_guest`` ではなく ``community.vmware.vmware_guest`` を使用する必要があります。"

#~ msgid "This way, the examples do not depend on the ``collections`` directive of the playbook."
#~ msgstr "この方法では、Playbook の ``collections`` ディレクティブに依存しません。"

#~ msgid "Functional tests"
#~ msgstr "機能テスト"

#~ msgid "Writing new tests"
#~ msgstr "新規テストの作成"

#~ msgid "If you are writing a new collection of integration tests, there are a few VMware-specific things to note beyond the standard Ansible :ref:`integration testing<testing_integration>` process."
#~ msgstr "統合テストの新しいコレクションを作成している場合は、標準の Ansible の :ref:`統合テスト<testing_integration>` プロセス以外に注意すべき VMware 固有の事項がいくつかあります。"

#~ msgid "The test-suite uses a set of common, pre-defined vars located `in prepare_vmware_tests <https://github.com/ansible-collections/community.vmware/tree/main/tests/integration/targets/test/integration/targets/prepare_vmware_tests/>`_ role. The resources defined there are automatically created by importing that role at the start of your test:"
#~ msgstr "テストスイートは、`prepare_vmware_tests <https://github.com/ansible-collections/community.vmware/tree/main/tests/integration/targets/test/integration/targets/prepare_vmware_tests/>`_ ロールにある一般的な事前定義済みの変数のセットを使用します。ここに定義されたリソースは、テストの開始時にそのロールをインポートして自動的に作成されます。"

#~ msgid "This will give you a ready to use cluster, datacenter, datastores, folder, switch, dvswitch, ESXi hosts, and VMs."
#~ msgstr "これにより、クラスター、データセンター、データストア、ディレクトリー、スイッチ、dvSwitch、ESXi ホスト、および仮想マシンを使用する準備が整います。"

#~ msgid "No need to create too much resources"
#~ msgstr "リソースを過剰に作成する必要なし"

#~ msgid "Most of the time, it's not necessary to use ``with_items`` to create multiple resources. By avoiding it, you speed up the test execution and you simplify the clean up afterwards."
#~ msgstr "多くの場合、``with_items`` を使用して複数のリソースの作成を行う必要はありません。回避することで、テストの実行を迅速化して、後でクリーンアップを単純化できます。"

#~ msgid "VM names should be predictable"
#~ msgstr "仮想マシン名は、名前で内容が予測できるものにする"

#~ msgid "If you need to create a new VM during your test, you can use ``test_vm1``, ``test_vm2`` or ``test_vm3``. This way it will be automatically clean up for you."
#~ msgstr "テスト中に新しい仮想マシンを作成する必要がある場合は、``test_vm1``、``test_vm2``、または ``test_vm3`` を使用できます。このように、自動的にクリーンアップされます。"

#~ msgid "Avoid the common boiler plate code in your test playbook"
#~ msgstr "テスト Playbook で一般的なボイラールのコードを回避"

#~ msgid "From Ansible 2.10, the test suite uses `modules_defaults`. This module allow us to preinitialize the following default keys of the VMware modules:"
#~ msgstr "Ansible 2.10 以降では、テストスイートは `modules_defaults` を使用します。このモジュールにより、以下の VMware モジュールのデフォルトキーを事前に初期化できます。"

#~ msgid "hostname"
#~ msgstr "hostname"

#~ msgid "username"
#~ msgstr "username"

#~ msgid "password"
#~ msgstr "password"

#~ msgid "validate_certs"
#~ msgstr "validate_certs"

#~ msgid "For example, the following block:"
#~ msgstr "たとえば、以下のブロックの場合:"

#~ msgid "should be simplified to just:"
#~ msgstr "以下を単純化する必要があります。"

#~ msgid "Typographic convention"
#~ msgstr "表記規則"

#~ msgid "Nomenclature"
#~ msgstr "命名法"

#~ msgid "VMware, not VMWare or vmware"
#~ msgstr "VMware (VMWare または vmware ではありません)"

#~ msgid "ESXi, not esxi or ESXI"
#~ msgstr "ESXi (esxi または ESXI ではありません)"

#~ msgid "vCenter, not vcenter or VCenter"
#~ msgstr "vCenter (vcenter または VCenter ではありません)"

#~ msgid "We also refer to vcsim's Go implementation with ``govcsim``. This to avoid any confusion with the outdated implementation."
#~ msgstr "また、``govcsim`` を使用した vcsim の Go 実装も参照します。これは、古い実装との混乱を回避するためのものです。"

#~ msgid "The Ansible VMware REST collection (on `Galaxy <https://galaxy.ansible.com/vmware/vmware_rest>`_, source code `repository <https://github.com/ansible-collections/vmware.vmware_rest>`_) is maintained by Red Hat and the community."
#~ msgstr "Ansible VMware REST コレクション (`Galaxy <https://galaxy.ansible.com/vmware/vmware_rest>`_ ではソースコード `repository <https://github.com/ansible-collections/vmware.vmware_rest>`_) は、Red Hat とコミュニティーにより維持されます。"

#~ msgid "The modules of the vmware_rest collection are autogenerated by another tool called `vmware_rest_code_generator <https://github.com/ansible-collections/vmware_rest_code_generator>`."
#~ msgstr "vmware_rest コレクションのモジュールは、`vmware_rest_code_generator <https://github.com/ansible-collections/vmware_rest_code_generator>` と呼ばれる別のツールにより自動生成されます。"

#~ msgid "If you would like to contribute a change, we would appreciate if you:"
#~ msgstr "変更に貢献したい場合は、以下をご用意ください。"

#~ msgid "submit a Github Pull Request (PR) against the vmware_rest_code_generator project"
#~ msgstr "vmware_rest_code_generator プロジェクトに対して Github Pull Request (PR) を送信します。"

#~ msgid "but also ensure the generated modules are compliant with our quality criteria."
#~ msgstr "ただし、生成されたモジュールが品質基準に準拠していることを確認します。"

#~ msgid "You will need:"
#~ msgstr "以下が必要になります。"

#~ msgid "Python 3.6 or greater"
#~ msgstr "Python 3.6 以降"

#~ msgid "the `tox <https://tox.readthedocs.io/en/latest/install.html>` command"
#~ msgstr "`tox <https://tox.readthedocs.io/en/latest/install.html>` コマンド"

#~ msgid "vmware_rest_code_generator"
#~ msgstr "vmware_rest_code_generator"

#~ msgid "Your contribution should follow the coding style of `Black <https://github.com/psf/black>`. To run the code formatter, just run:"
#~ msgstr "貢献は、`Black <https://github.com/psf/black>` のコーディングスタイルに従う必要があります。コードフォーマッターを実行するには、以下を実行します。"

#~ msgid "To regenerate the vmware_rest collection, you can use the following commands:"
#~ msgstr "vmware_rest コレクションを再生成するには、以下のコマンドを使用できます。"

#~ msgid "If you also want to update the EXAMPLE section of the modules, run:"
#~ msgstr "モジュールの EXAMPLE セクションも更新する場合は、以下を実行します。"

#~ msgid "Testing with ansible-test"
#~ msgstr "ansible-test を使用したテスト"

#~ msgid "All the modules are covered by a functional test. The tests are located in the :file:`tests/integration/targets/`."
#~ msgstr "すべてのモジュールは、機能テストで対応しています。テストは、:file:`tests/integration/targets/` に置かれます。"

#~ msgid "To run the tests, you will need a vcenter instance and an ESXi."
#~ msgstr "テストを実行するには、vcenter インスタンスと ESXi が必要です。"

#~ msgid "black code formatter"
#~ msgstr "ブラックコードフォーマッター"

#~ msgid "We follow the coding style of `Black <https://github.com/psf/black>`. You can run the code formatter with the following command."
#~ msgstr "`Black <https://github.com/psf/black>` のコーディングスタイルに準拠しています。以下のコマンドでコードフォーマッターを実行できます。"

#~ msgid "sanity tests"
#~ msgstr "健全性テスト"

#~ msgid "Here we use Python 3.8, the minimal version is 3.6."
#~ msgstr "ここでは Python 3.8 を使用します。最小バージョンは 3.6 です。"

#~ msgid "These tests should be run against your test environment."
#~ msgstr "これらのテストは、テスト環境に対して実行する必要があります。"

#~ msgid "..warning:: The test suite will delete all the existing DC from your test environment."
#~ msgstr "..警告:: テストスイートは、テスト環境から既存の DC をすべて削除します。"

#~ msgid "First, prepare a configuration file, we call it :file:`/tmp/inventory-vmware_rest` in this example:"
#~ msgstr "まず設定ファイルを準備し、この例では :file:`/tmp/inventory-vmware_rest` とします。"

#~ msgid "To run the tests, use the following command. You may want to adjust the Python version."
#~ msgstr "テストを実行するには、以下のコマンドを使用して Python バージョンを調整できます。"

#~ msgid "Ask for advice on IRC, on the ``#ansible-devel`` Freenode channel"
#~ msgstr "Freenode チャンネル ``#ansible-devel`` の IRC で質問してください。"

#~ msgid "Ansible Tower®"
#~ msgstr "Ansible Tower®"

#~ msgid "If you're a developer, one of the most valuable things you can do is look at the GitHub issues list and help fix bugs.  We almost always prioritize bug fixing over feature development."
#~ msgstr "開発者にとって、最も価値のあることの 1 つが、GitHub の問題を確認し、バグ修正を手伝うことです。バグ修正は、ほとんど常に、機能開発よりも優先されるためです。"

#~ msgid "Even for non developers, helping to test pull requests for bug fixes and features is still immensely valuable.  Ansible users who understand writing playbooks and roles should be able to add integration tests and so GitHub pull requests with integration tests that show bugs in action will also be a great way to help."
#~ msgstr "開発者ではなくても、バグの修正や機能のプル要求のテストを手伝うことは非常に価値のあることです。Ansible ユーザーが Playbook やロールの書き方を熟知していれば統合テストを追加できるため、バグが実際に動かしている様子を示す統合テストが付いた GitHub プル要求も、大きな助けになるでしょう。"

#~ msgid "If the issue persists, please contact us in ``#ansible-devel`` on Freenode IRC."
#~ msgstr "問題が解決しない場合は、Freenode IRC の ``#ansible-devel`` にお問い合わせください。"

#~ msgid "``skip/windows/2008`` - Skip tests on Windows Server 2008."
#~ msgstr "``skip/windows/2008`` - Windows Server 2008 のテストを省略します。"

#~ msgid "For questions about integration tests reach out to @mattclay or @gundalow on GitHub or ``#ansible-devel`` on IRC."
#~ msgstr "インテグレーションテストに関する質問は、GitHub で @mattclay または @gundalow、または IRC で ``#ansible-devel`` にお問い合わせください。"

#~ msgid "Avoiding pulling new Docker images"
#~ msgstr "新規 Docker イメージのプルの回避"

#~ msgid "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."
#~ msgstr "最新のコンテナーイメージをプルしないようにするには、``--docker-no-pull`` オプションを使用します。これは、ダウンロードに利用できないカスタムのローカルイメージを使用する場合に必要です。"

#~ msgid "Python 2"
#~ msgstr "Python 2"

#~ msgid "Most container images are for testing with Python 2:"
#~ msgstr "ほとんどのコンテナーイメージは、Python 2 でテストするためのものです。"

#~ msgid "centos6"
#~ msgstr "centos6"

#~ msgid "centos7"
#~ msgstr "centos7"

#~ msgid "fedora28"
#~ msgstr "fedora28"

#~ msgid "opensuse15py2"
#~ msgstr "opensuse15py2"

#~ msgid "ubuntu1404"
#~ msgstr "ubuntu1404"

#~ msgid "ubuntu1604"
#~ msgstr "ubuntu1604"

#~ msgid "Python 3"
#~ msgstr "Python 3"

#~ msgid "To test with Python 3 use the following images:"
#~ msgstr "Python 3 でテストするには、以下のイメージを使用します。"

#~ msgid "centos8"
#~ msgstr "centos8"

#~ msgid "fedora32"
#~ msgstr "fedora32"

#~ msgid "opensuse15"
#~ msgstr "opensuse15"

#~ msgid "ubuntu1804"
#~ msgstr "ubuntu1804"

#~ msgid "last-line-main-call"
#~ msgstr "last-line-main-call"

#~ msgid "Call to ``main()`` not the last line (or ``removed_module()`` in the case of deprecated & docs only modules)"
#~ msgstr "最終行以外の ``main()`` の呼出し (または、非推奨およびドキュメントのみのモジュールでは ``removed_module()``)。"

#~ msgid "missing-if-name-main"
#~ msgstr "missing-if-name-main"

#~ msgid "Next to last line is not ``if __name__ == \"__main__\":``"
#~ msgstr "最後の行の隣になるものは、``if __name__ == \"__main__\":`` ではない"

#~ msgid "missing-main-call"
#~ msgstr "missing-main-call"

#~ msgid "Did not find a call to ``main()`` (or ``removed_module()`` in the case of deprecated & docs only modules)"
#~ msgstr "``main()`` への呼出しが見つからなかった (非推奨またはドキュメントのみのモジュールの場合は ``removed_module()``)。"

#~ msgid "missing-python-doc"
#~ msgstr "missing-python-doc"