# This file is distributed under the same license as the Ansible package.
# FIRST AUTHOR <EMAIL@ADDRESS>, 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: Ansible devel\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-02-23 10:50+0100\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Generated-By: Babel 2.9.0\n"
#: ../../rst/plugins/action.rst:4
msgid "Action Plugins"
msgstr "action プラグイン"
#: ../../rst/plugins/action.rst:10
msgid "Action plugins act in conjunction with :ref:`modules <working_with_modules>` to execute the actions required by playbook tasks. They usually execute automatically in the background doing prerequisite work before modules execute."
msgid "You can enable a custom action plugin by either dropping it into the ``action_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the action plugin directory sources configured in :ref:`ansible.cfg <ansible_configuration_settings>`."
msgid "Use ``ansible-doc -l`` to see the list of available modules. Use ``ansible-doc <name>`` to see specific documentation and examples, this should note if the module has a corresponding action plugin."
msgid "Become plugins work to ensure that Ansible can use certain privilege escalation systems when running the basic commands to work with the target machine as well as the modules required to execute the tasks specified in the play."
msgid "These utilities (``sudo``, ``su``, ``doas``, and so on) generally let you 'become' another user to execute a command with the permissions of that user."
msgid "The become plugins shipped with Ansible are already enabled. Custom plugins can be added by placing them into a ``become_plugins`` directory adjacent to your play, inside a role, or by placing them in one of the become plugin directory sources configured in :ref:`ansible.cfg <ansible_configuration_settings>`."
msgstr "Ansible に同梱されている become プラグインはすでに有効になっています。カスタムのプラグインを追加するには、ロール内のプレイの隣りにある ``become_plugins`` ディレクトリーに置くか、:ref:`ansible.cfg <ansible_configuration_settings>` で設定した become プラグインのディレクトリーソースの 1 つに配置します。"
#: ../../rst/plugins/become.rst:33
msgid "Using Become Plugins"
msgstr "become プラグインの使用"
#: ../../rst/plugins/become.rst:35
msgid "In addition to the default configuration settings in :ref:`ansible_configuration_settings` or the ``--become-method`` command line option, you can use the ``become_method`` keyword in a play or, if you need to be 'host specific', the connection variable ``ansible_become_method`` to select the plugin to use."
msgid "You can use ``ansible-doc -t become -l`` to see the list of available plugins. Use ``ansible-doc -t become <plugin name>`` to see specific documentation and examples."
msgstr "``ansible-doc -t become -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t become <plugin name>`` を使用して、特定のドキュメントと例を参照してください。"
msgid "The default cache plugin is the :ref:`memory <memory_cache>` plugin, which only caches the data for the current execution of Ansible. Other plugins with persistent storage are available to allow caching the data across runs. Some of these cache plugins write to files, others write to databases."
msgid "You can use different cache plugins for inventory and facts. If you enable inventory caching without setting an inventory-specific cache plugin, Ansible uses the fact cache plugin for both facts and inventory."
msgid "Fact caching is always enabled. However, only one fact cache plugin can be active at a time. You can select the cache plugin to use for fact caching in the Ansible configuration, either with an environment variable:"
msgid "To enable a custom cache plugin, save it in a ``cache_plugins`` directory adjacent to your play, inside a role, or in one of the directory sources configured in :ref:`ansible.cfg <ansible_configuration_settings>`."
msgid "You also need to configure other settings specific to each plugin. Consult the individual plugin documentation or the Ansible :ref:`configuration <ansible_configuration_settings>` for more details."
msgid "Inventory caching is disabled by default. To cache inventory data, you must enable inventory caching and then select the specific cache plugin you want to use. Not all inventory plugins support caching, so check the documentation for the inventory plugin(s) you want to use. You can enable inventory caching with an environment variable:"
msgid "If you enable caching for inventory plugins without selecting an inventory-specific cache plugin, Ansible falls back to caching inventory with the fact cache plugin you configured. Consult the individual inventory plugin documentation or the Ansible :ref:`configuration <ansible_configuration_settings>` for more details."
msgid "Cache plugins are used automatically once they are enabled."
msgstr "cache プラグインは、有効になると自動的に使用されます。"
#: ../../rst/plugins/cache.rst:118
msgid "You can use ``ansible-doc -t cache -l`` to see the list of available plugins. Use ``ansible-doc -t cache <plugin name>`` to see specific documentation and examples."
msgid "Callback plugins enable adding 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, but can also be used to add additional output, integrate with other tools and marshall the events to a storage backend."
msgid "The :ref:`log_plays <log_plays_callback>` callback is an example of how to record playbook events to a log file, and the :ref:`mail <mail_callback>` callback sends email on playbook failures."
msgid "You can activate a custom callback by either dropping it into a ``callback_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the callback directory sources configured in :ref:`ansible.cfg <ansible_configuration_settings>`."
msgid "Plugins are loaded in alphanumeric order. For example, a plugin implemented in a file named `1_first.py` would run before a plugin file named `2_second.py`."
msgid "Most callbacks shipped with Ansible are disabled by default and need to be enabled in your :ref:`ansible.cfg <ansible_configuration_settings>` file in order to function. For example:"
msgid "Setting a callback plugin for ``ansible-playbook``"
msgstr "``ansible-playbook``の callback プラグインの設定"
#: ../../rst/plugins/callback.rst:42
msgid "You can only have one plugin be the main manager of your console output. If you want to replace the default, you should define CALLBACK_TYPE = stdout in the subclass and then configure the stdout plugin in :ref:`ansible.cfg <ansible_configuration_settings>`. For example:"
msgid "Setting a callback plugin for ad hoc commands"
msgstr "アドホックコマンドへの callback プラグインの設定"
#: ../../rst/plugins/callback.rst:59
msgid "The :ref:`ansible` ad hoc command specifically uses a different callback plugin for stdout, so there is an extra setting in :ref:`ansible_configuration_settings` you need to add to use the stdout callback defined above:"
msgid "You can also set this as an environment variable:"
msgstr "これを環境変数として設定することもできます。"
#: ../../rst/plugins/callback.rst:79
msgid "You can use ``ansible-doc -t callback -l`` to see the list of available plugins. Use ``ansible-doc -t callback <plugin name>`` to see specific documents and examples."
msgid "Cliconf plugins are abstractions over the CLI interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices."
msgid "These plugins generally correspond one-to-one to network device platforms. Ansible loads the appropriate cliconf plugin automatically based on the ``ansible_network_os`` variable."
msgid "The cliconf plugin to use is determined automatically from the ``ansible_network_os`` variable. There should be no reason to override this functionality."
msgid "Most cliconf plugins can operate without configuration. A few have additional options that can be set to affect how tasks are translated into CLI commands."
msgid "These plugins have migrated to collections on `Ansible Galaxy <https://galaxy.ansible.com>`_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several cliconf plugins. To list all available cliconf plugins on your control node, type ``ansible-doc -t cliconf -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t cliconf``."
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."
msgid "By default, Ansible ships with several plugins. The most commonly used are the :ref:`paramiko SSH<paramiko_ssh_connection>`, native ssh (just called :ref:`ssh<ssh_connection>`), and :ref:`local<local_connection>` connection types. All of these can be used in playbooks and with :command:`/usr/bin/ansible` to decide how you want to talk to remote machines."
msgid "Because ssh is the default protocol used in system administration and the protocol most used in Ansible, ssh options are included in the command line tools. See :ref:`ansible-playbook` for more details."
msgid "You can extend Ansible to support other transports (such as SNMP or message bus) by dropping a custom plugin into the ``connection_plugins`` directory."
msgid "You can set the connection plugin globally via :ref:`configuration<ansible_configuration_settings>`, at the command line (``-c``, ``--connection``), as a :ref:`keyword <playbook_keywords>` in your play, or by setting a :ref:`variable<behavioral_parameters>`, most often in your inventory. For example, for Windows machines you might want to set the :ref:`winrm <winrm_connection>` plugin as an inventory variable."
msgid "Most connection plugins can operate with minimal configuration. By default they use the :ref:`inventory hostname<inventory_hostnames_lookup>` and defaults to find the target host."
msgid "Plugins are self-documenting. Each plugin should document its configuration options. The following are connection variables common to most connection plugins:"
msgid "Each plugin might also have a specific version of a variable that overrides the general version. For example, ``ansible_ssh_host`` for the :ref:`ssh <ssh_connection>` plugin."
msgid "You can use ``ansible-doc -t connection -l`` to see the list of available plugins. Use ``ansible-doc -t connection <plugin name>`` to see detailed documentation and examples."
msgid "Httpapi plugins tell Ansible how to interact with a remote device's HTTP-based API and execute tasks on the device."
msgstr "httpapi プラグインは、Ansible に対して、リモートデバイスの HTTP ベースの API と対話して、そのデバイスでタスクを実行する方法を指示します。"
#: ../../rst/plugins/httpapi.rst:13
msgid "Each plugin represents a particular dialect of API. Some are platform-specific (Arista eAPI, Cisco NXAPI), while others might be usable on a variety of platforms (RESTCONF). Ansible loads the appropriate httpapi plugin automatically based on the ``ansible_network_os`` variable."
msgid "You can extend Ansible to support other APIs by dropping a custom plugin into the ``httpapi_plugins`` directory. See :ref:`developing_plugins_httpapi` for details."
msgstr "``httpapi_plugins`` ディレクトリーにカスタムのプラグインを置いて、Ansible が他の API をサポートするように拡張できます。詳細は、「:ref:`developing_plugins_httpapi`」を参照してください。"
#: ../../rst/plugins/httpapi.rst:26
msgid "Using httpapi plugins"
msgstr "httpapi プラグインの使用"
#: ../../rst/plugins/httpapi.rst:28
msgid "The httpapi plugin to use is determined automatically from the ``ansible_network_os`` variable."
msgid "The following sample playbook shows the httpapi plugin for an Arista network device, assuming an inventory variable set as ``ansible_network_os=eos`` for the httpapi plugin to trigger off:"
msgid "These plugins have migrated to collections on `Ansible Galaxy <https://galaxy.ansible.com>`_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several httpapi plugins. To list all available httpapi plugins on your control node, type ``ansible-doc -t httpapi -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t httpapi``."
msgid "Inventory plugins allow users to point at data sources to compile the inventory of hosts that Ansible uses to target tasks, either using the ``-i /path/to/file`` and/or ``-i 'host1, host2'`` command line parameters or from other configuration sources."
msgid "In some circumstances, for example, if the inventory plugin does not use a YAML configuration file, you may need to enable the specific plugin. You can do this by setting ``enable_plugins`` in your :ref:`ansible.cfg <ansible_configuration_settings>` file in the ``[inventory]`` section. Modifying this will override the default list of enabled plugins. Here is the default list of enabled plugins that ships with Ansible:"
msgid "If the plugin is in a collection, use the fully qualified name:"
msgstr "プラグインをコレクションで使用する場合は、完全修飾名を使用してください。"
#: ../../rst/plugins/inventory.rst:38
msgid "Using inventory plugins"
msgstr "inventory プラグインの使用"
#: ../../rst/plugins/inventory.rst:40
msgid "To use an inventory plugin, you must provide an inventory source. Most of the time this is a file containing host information or a YAML configuration file with options for the plugin. You can use the ``-i`` flag to provide inventory sources or configure a default inventory path."
msgid "To start using an inventory plugin with a YAML configuration source, create a file with the accepted filename schema documented for the plugin in question, then add ``plugin: plugin_name``. Use the fully qualified name if the plugin is in a collection."
msgid "Each plugin should document any naming restrictions. In addition, the YAML config file must end with the extension ``yml`` or ``yaml`` to be enabled by default with the ``auto`` plugin (otherwise, see the section above on enabling plugins)."
msgid "If you are using an inventory plugin in a playbook-adjacent collection and want to test your setup with ``ansible-inventory``, use the ``--playbook-dir`` flag."
msgid "Your inventory source might be a directory of inventory configuration files. The constructed inventory plugin only operates on those hosts already in inventory, so you may want the constructed inventory configuration parsed at a particular point (such as last). Ansible parses the directory recursively, alphabetically. You cannot configure the parsing approach, so name your files to make it work predictably. Inventory plugins that extend constructed features directly can work around that restriction by adding constructed options in addition to the inventory plugin options. Otherwise, you can use ``-i`` with multiple sources to impose a specific order, for example ``-i demo.aws_ec2.yml -i clouds.yml -i constructed.yml``."
msgid "You can create dynamic groups using host variables with the constructed ``keyed_groups`` option. The option ``groups`` can also be used to create groups and ``compose`` creates and modifies host variables. Here is an aws_ec2 example utilizing constructed features:"
msgid "If a host does not have the variables in the configuration above (in other words, ``tags.Name``, ``tags``, ``private_ip_address``), the host will not be added to groups other than those that the inventory plugin creates and the ``ansible_host`` host variable will not be modified."
msgid "Inventory plugins that support caching can use the general settings for the fact cache defined in the ``ansible.cfg`` file's ``[defaults]`` section or define inventory-specific settings in the ``[inventory]`` section. Individual plugins can define plugin-specific cache settings in their config file:"
msgid "Here is an example of setting inventory caching with some fact caching defaults for the cache plugin used and the timeout in an ``ansible.cfg`` file:"
msgid "You can use ``ansible-doc -t inventory -l`` to see the list of available plugins. Use ``ansible-doc -t inventory <plugin name>`` to see plugin-specific documentation and examples."
msgid "Lookup plugins are an Ansible-specific extension to the Jinja2 templating language. You can use lookup plugins to access data from outside sources (files, databases, key/value stores, APIs, and other services) within your playbooks. Like all :ref:`templating <playbooks_templating>`, lookups execute and are evaluated on the Ansible control machine. Ansible makes the data returned by a lookup plugin available using the standard templating system. You can use lookup plugins to load variables or templates with information from external sources."
msgid "Lookups are executed with a working directory relative to the role or play, as opposed to local tasks, which are executed relative the executed script."
msgid "Ansible enables all lookup plugins it can find. You can activate a custom lookup by either dropping it into a ``lookup_plugins`` directory adjacent to your play, inside the ``plugins/lookup/`` directory of a collection you have installed, inside a standalone role, or in one of the lookup directory sources configured in :ref:`ansible.cfg <ansible_configuration_settings>`."
msgid "You can use lookup plugins anywhere you can use templating in Ansible: in a play, in variables file, or in a Jinja2 template for the :ref:`template <template_module>` module."
msgid "Lookups are an integral part of loops. Wherever you see ``with_``, the part after the underscore is the name of a lookup. For this reason, most lookups output lists and take lists as input; for example, ``with_items`` uses the :ref:`items <items_lookup>` lookup::"
msgid "You can combine lookups with :ref:`filters <playbooks_filters>`, :ref:`tests <playbooks_tests>` and even each other to do some complex data generation and manipulation. For example::"
msgid "You can control how errors behave in all lookup plugins by setting ``errors`` to ``ignore``, ``warn``, or ``strict``. The default setting is ``strict``, which causes the task to fail if the lookup returns an error. For example:"
msgid "In Ansible 2.5, a new Jinja2 function called ``query`` was added for invoking lookup plugins. The difference between ``lookup`` and ``query`` is largely that ``query`` will always return a list. The default behavior of ``lookup`` is to return a string of comma separated values. ``lookup`` can be explicitly configured to return a list using ``wantlist=True``."
msgid "This feature provides an easier and more consistent interface for interacting with the new ``loop`` keyword, while maintaining backwards compatibility with other uses of ``lookup``."
msgid "Additionally, ``q`` was introduced as a shortform of ``query``:"
msgstr "また、``query`` の短縮形となる ``q`` が導入されました。"
#: ../../rst/plugins/lookup.rst:138
msgid "You can use ``ansible-doc -t lookup -l`` to see the list of available plugins. Use ``ansible-doc -t lookup <plugin name>`` to see specific documents and examples."
msgid "Netconf plugins are abstractions over the Netconf interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices."
msgid "These plugins generally correspond one-to-one to network device platforms. Ansible loads the appropriate netconf plugin automatically based on the ``ansible_network_os`` variable. If the platform supports standard Netconf implementation as defined in the Netconf RFC specification, Ansible loads the ``default`` netconf plugin. If the platform supports propriety Netconf RPCs, Ansible loads the platform-specific netconf plugin."
msgid "The netconf plugin to use is determined automatically from the ``ansible_network_os`` variable. There should be no reason to override this functionality."
msgid "Most netconf plugins can operate without configuration. A few have additional options that can be set to affect how tasks are translated into netconf commands. A ncclient device specific handler name can be set in the netconf plugin or else the value of ``default`` is used as per ncclient device handler."
msgid "These plugins have migrated to collections on `Ansible Galaxy <https://galaxy.ansible.com>`_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several netconf plugins. To list all available netconf plugins on your control node, type ``ansible-doc -t netconf -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t netconf``."
msgid "Plugins are pieces of code that augment Ansible's core functionality. Ansible uses a plugin architecture to enable a rich, flexible and expandable feature set."
msgid "This section covers the various types of plugins that are included with Ansible:"
msgstr "本セクションでは、Ansible に含まれるさまざまなプラグインを説明します。"
#: ../../rst/plugins/plugins.rst:37
msgid ":ref:`ansible_configuration_settings`"
msgstr ":ref:`ansible_configuration_settings`"
#: ../../rst/plugins/plugins.rst:38
msgid "Ansible configuration documentation and settings"
msgstr "Ansible 設定ドキュメントおよび設定"
#: ../../rst/plugins/plugins.rst:39
msgid ":ref:`command_line_tools`"
msgstr ":ref:`command_line_tools`"
#: ../../rst/plugins/plugins.rst:40
msgid "Ansible tools, description and options"
msgstr "Ansible ツール、説明、およびオプション"
#: ../../rst/plugins/shell.rst:4
msgid "Shell Plugins"
msgstr "shell プラグイン"
#: ../../rst/plugins/shell.rst:10
msgid "Shell plugins work to ensure that the basic commands Ansible runs are properly formatted to work with the target machine and allow the user to configure certain behaviors related to how Ansible executes tasks."
msgid "You can add a custom shell plugin by dropping it into a ``shell_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the shell plugin directory sources configured in :ref:`ansible.cfg <ansible_configuration_settings>`."
msgid "You should not alter which plugin is used unless you have a setup in which the default ``/bin/sh`` is not a POSIX compatible shell or is not available for execution."
msgid "In addition to the default configuration settings in :ref:`ansible_configuration_settings`, you can use the connection variable :ref:`ansible_shell_type <ansible_shell_type>` to select the plugin to use. In this case, you will also want to update the :ref:`ansible_shell_executable <ansible_shell_executable>` to match."
msgid "All strategy plugins shipped with Ansible are enabled by default. You can enable a custom strategy plugin by putting it in one of the lookup directory sources configured in :ref:`ansible.cfg <ansible_configuration_settings>`."
msgid "Only one strategy plugin can be used in a play, but you can use different ones for each play in a playbook or ansible run. The default is the :ref:`linear <linear_strategy>` plugin. You can change this default in Ansible :ref:`configuration <ansible_configuration_settings>` using an environment variable:"
msgid "You can use ``ansible-doc -t strategy -l`` to see the list of available plugins. Use ``ansible-doc -t strategy <plugin name>`` to see plugin-specific specific documentation and examples."
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."
msgid "The :ref:`host_group_vars <host_group_vars_vars>` plugin shipped with Ansible enables reading variables from :ref:`host_variables` and :ref:`group_variables`."
msgid "You can activate a custom vars plugin by either dropping it into a ``vars_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the directory sources configured in :ref:`ansible.cfg <ansible_configuration_settings>`."
msgstr "カスタムの vars プラグインを有効にするには、カスタムのプラグインを、ロール内のプレイの隣りにある ``vars_plugins`` ディレクトリーに置くか、:ref:`ansible.cfg <ansible_configuration_settings>` で設定したディレクトリーソースの 1 つに置きます。"
#: ../../rst/plugins/vars.rst:24
msgid "Most vars plugins are disabled by default. To enable a vars plugin, set ``vars_plugins_enabled`` in the ``defaults`` section of :ref:`ansible.cfg <ansible_configuration_settings>` or set the ``ANSIBLE_VARS_ENABLED`` environment variable to the list of vars plugins you want to execute. By default, the :ref:`host_group_vars <host_group_vars_vars>` plugin shipped with Ansible is enabled."
msgstr "ほとんどの vars プラグインはデフォルトで無効になっています。vars プラグインを有効にするには、:ref:`ansible.cfg <ansible_configuration_settings>` の ``defaults`` セクションで ``vars_plugins_enabled`` を設定するか、実行する vars プラグインの一覧に ``ANSIBLE_VARS_ENABLED`` 環境変数を設定します。デフォルトでは、Ansible に同梱される :ref:`host_group_vars <host_group_vars_vars>` プラグインが有効になっています。"
#: ../../rst/plugins/vars.rst:26
msgid "Starting in Ansible 2.10, you can use vars plugins in collections. All vars plugins in collections must be explicitly enabled and must use the fully qualified collection name in the format ``namespace.collection_name.vars_plugin_name``."
msgstr "Ansible 2.10 以降では、コレクションで vars プラグインを使用できます。コレクションのすべての vars プラグインは明示的に有効で、``namespace.collection_name.vars_plugin_name`` 形式で完全修飾コレクション名を使用する必要があります。"
#: ../../rst/plugins/vars.rst:36
msgid "Using vars plugins"
msgstr "vars プラグインの使用"
#: ../../rst/plugins/vars.rst:38
msgid "By default, vars plugins are used on demand automatically after they are enabled."
msgid "Starting in Ansible 2.10, vars plugins can be made to run at specific times. `ansible-inventory` does not use these settings, and always loads vars plugins."
msgstr "Ansible 2.10 以降、vars プラグインは特定のタイミングで実行できます。`ansible-inventory` はこれらの設定を使用せず、常に vars プラグインを読み込みます。"
#: ../../rst/plugins/vars.rst:42
msgid "The global setting ``RUN_VARS_PLUGINS`` can be set in ``ansible.cfg`` using ``run_vars_plugins`` in the ``defaults`` section or by the ``ANSIBLE_RUN_VARS_PLUGINS`` environment variable. The default option, ``demand``, runs any enabled vars plugins relative to inventory sources whenever variables are demanded by tasks. You can use the option ``start`` to run any enabled vars plugins relative to inventory sources after importing that inventory source instead."
msgid "You can also control vars plugin execution on a per-plugin basis for vars plugins that support the ``stage`` option. To run the :ref:`host_group_vars <host_group_vars_vars>` plugin after importing inventory you can add the following to :ref:`ansible.cfg <ansible_configuration_settings>`:"
msgstr "また、``stage`` オプションをサポートする vars プラグインの場合は、プラグインごとに vars プラグインの実行を制御することもできます。インベントリーのインポート後に :ref:`host_group_vars <host_group_vars_vars>` プラグインを実行するには、以下を :ref:`ansible.cfg <ansible_configuration_settings>` に追加します:"
#: ../../rst/plugins/vars.rst:54
msgid "Plugin Lists"
msgstr "プラグイン一覧"
#: ../../rst/plugins/vars.rst:56
msgid "You can use ``ansible-doc -t vars -l`` to see the list of available plugins. Use ``ansible-doc -t vars <plugin name>`` to see specific plugin-specific documentation and examples."
msgstr "``ansible-doc -t vars -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t vars <plugin name>`` を使用して、プラグイン固有のドキュメントと例を参照してください。"
