# SOME DESCRIPTIVE TITLE. # Copyright (C) 2021 Red Hat, Inc. # This file is distributed under the same license as the Ansible package. # FIRST AUTHOR , 2021. # msgid "" msgstr "" "Project-Id-Version: Ansible devel\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-03-08 20:25+0100\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \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/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 "required" #: ../../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 ``namespace``." msgstr "``namespace`` と同じ文字制限があります。" #: ../../rst/dev_guide/collections_galaxy_meta.rst:73 msgid "version |br|" msgstr "version:" #: ../../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 "Markdown (.md) ファイルへのパス。" #: ../../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 "list |_|" #: ../../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 (url) @nicks:irc/im.site#channel'." msgstr "名前または形式には、「Full Name (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 `_ licenses" msgstr "現在 Ansible Galaxy は `SPDX `_ ライセンスのみ受け付けます。" #: ../../rst/dev_guide/collections_galaxy_meta.rst:165 msgid "This key is mutually exclusive with ``license_file``." msgstr "このキーは、``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 ``license``." msgstr "このキーは、``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 ``namespace`` and ``name``." msgstr "タグ名には、``namespace`` および ``name`` と同じ文字要件があります。" #: ../../rst/dev_guide/collections_galaxy_meta.rst:205 msgid "dependencies |br|" msgstr "依存関係 |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 ``namespace.name``." msgstr "dict のキーはコレクションラベル ``namespace.name`` です。" #: ../../rst/dev_guide/collections_galaxy_meta.rst:217 msgid "The value is a version range `specifiers `_." msgstr "この値は、`指定子 `_ のバージョン範囲です。" #: ../../rst/dev_guide/collections_galaxy_meta.rst:219 msgid "Multiple version range specifiers can be set and are separated by ``,``." msgstr "複数のバージョン範囲指定子を設定でき、``,`` で区切ることができます。" #: ../../rst/dev_guide/collections_galaxy_meta.rst:225 msgid "repository |br|" msgstr "リポジトリー |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 "ドキュメント |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 "ホームページ |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 "問題 |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 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 ``fnmatch`` to match the files or directories." msgstr "ここでは、``fnmatch`` を使用してファイルまたはディレクトリーを照合します。" #: ../../rst/dev_guide/collections_galaxy_meta.rst:299 msgid "Some directories and files like ``galaxy.yml``, ``*.pyc``, ``*.retry``, and ``.git`` are always filtered." msgstr "``galaxy.yml``、``*.pyc``、``*.retry``、``.git`` などの一部のディレクトリーおよびファイルは常にフィルタリングされます。" #: ../../rst/dev_guide/collections_galaxy_meta.rst:304 msgid "Examples" msgstr "例" #: ../../rst/dev_guide/collections_galaxy_meta.rst:329 msgid ":ref:`developing_collections`" msgstr ":ref:`developing_collections`" #: ../../rst/dev_guide/collections_galaxy_meta.rst:330 msgid "Develop or modify a collection." msgstr "コレクションを開発するか、または変更します。" #: ../../rst/dev_guide/collections_galaxy_meta.rst:331 #: ../../rst/dev_guide/developing_api.rst:40 #: ../../rst/dev_guide/developing_collections.rst:809 #: ../../rst/dev_guide/developing_inventory.rst:413 #: ../../rst/dev_guide/developing_plugins.rst:496 #: ../../rst/dev_guide/testing_units_modules.rst:545 msgid ":ref:`developing_modules_general`" msgstr ":ref:`developing_modules_general`" #: ../../rst/dev_guide/collections_galaxy_meta.rst:332 #: ../../rst/dev_guide/developing_collections.rst:810 #: ../../rst/dev_guide/developing_plugins.rst:497 msgid "Learn about how to write Ansible modules" msgstr "Ansible モジュールの作成方法について" #: ../../rst/dev_guide/collections_galaxy_meta.rst:333 #: ../../rst/dev_guide/developing_collections.rst:805 msgid ":ref:`collections`" msgstr ":ref:`collections`" #: ../../rst/dev_guide/collections_galaxy_meta.rst:334 #: ../../rst/dev_guide/developing_collections.rst:806 msgid "Learn how to install and use collections." msgstr "コレクションのインストール方法および使用方法はこちらを参照してください。" #: ../../rst/dev_guide/collections_galaxy_meta.rst:335 #: ../../rst/dev_guide/developing_collections.rst:811 #: ../../rst/dev_guide/developing_core.rst:18 #: ../../rst/dev_guide/developing_modules.rst:48 #: ../../rst/dev_guide/developing_plugins.rst:498 msgid "`Mailing List `_" msgstr "`Mailing List `_" #: ../../rst/dev_guide/collections_galaxy_meta.rst:336 #: ../../rst/dev_guide/developing_collections.rst:812 #: ../../rst/dev_guide/developing_core.rst:19 #: ../../rst/dev_guide/developing_plugins.rst:499 msgid "The development mailing list" msgstr "開発メーリングリスト" #: ../../rst/dev_guide/collections_galaxy_meta.rst:337 #: ../../rst/dev_guide/developing_api.rst:46 #: ../../rst/dev_guide/developing_collections.rst:813 #: ../../rst/dev_guide/developing_core.rst:20 #: ../../rst/dev_guide/developing_inventory.rst:421 #: ../../rst/dev_guide/developing_modules.rst:50 #: ../../rst/dev_guide/developing_plugins.rst:500 #: ../../rst/dev_guide/style_guide/index.rst:277 msgid "`irc.freenode.net `_" msgstr "`irc.freenode.net `_" #: ../../rst/dev_guide/collections_galaxy_meta.rst:338 #: ../../rst/dev_guide/developing_api.rst:47 #: ../../rst/dev_guide/developing_collections.rst:814 #: ../../rst/dev_guide/developing_inventory.rst:422 #: ../../rst/dev_guide/developing_modules.rst:51 #: ../../rst/dev_guide/developing_plugins.rst:501 msgid "#ansible IRC chat channel" msgstr "IRC チャットチャンネル (#ansible)" #: ../../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 モジュールボイラープレートで構成される 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 `." msgstr "以下の手順では、ターゲットホストに ``localhost`` を使用していますが、同じ手順を使用してリモートホストに対してデバッグすることもできます。一時ファイルを使用せずにデバッグを行う簡単な方法は、「:ref:`簡単なデバッグ `」を参照してください。" #: ../../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 `_, then you'll have to make sure that the Python `requests library `_ 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 `_ が含まれる場合は、モジュールを実行する前に Python `requests library `_ がシステムにインストールされていることを確認する必要があります。" #: ../../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 "作成したモジュールコードではなく、モジュールのこのボイラープレートコードの一部に問題があると思われる場合は、このディレクトリーのファイルを変更できます。" #: ../../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 `_. 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 `_ 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 `_ を使用します。任意の破損ポイントで、コントロールノードのモジュールコードに ``import epdb; epdb.serve()`` を追加します。デバッガーに接続するには、``epdb.connect()`` を実行します。``host`` および ``port`` を指定する方法は、`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 `_ library is another very useful debugging tool." msgstr "`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 `_ first." msgstr "この API は、内部 Ansible の使用を目的としています。Ansible は、古いバージョンの API との後方互換性を妨げる可能性がある時点でこの API に変更を加える可能性があるため、Ansible では外部の使用はサポートされません。Playbook またはモジュールの実行のみに Python API を使用する場合は、まず `ansible-runner `_ を考慮してください。" #: ../../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 `Ansible Tower documentation `_." msgstr "Python 以外の言語からプログラムを使用して Ansible を使用する場合は、イベントを非同期的にトリガーするか、またはアクセス制御およびログの需要がある場合は、`Ansible Tower ドキュメント `_ を参照してください。" #: ../../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 `_." msgstr "``ansible`` コマンドラインツールのソースコード (``lib/ansible/cli/``) は `GitHub `_ で利用できます。" #: ../../rst/dev_guide/developing_api.rst:38 #: ../../rst/dev_guide/developing_plugins.rst:494 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:16 #: ../../rst/dev_guide/developing_inventory.rst:415 msgid ":ref:`developing_plugins`" msgstr ":ref:`developing_plugins`" #: ../../rst/dev_guide/developing_api.rst:43 #: ../../rst/dev_guide/developing_inventory.rst:416 msgid "How to develop plugins" msgstr "プラグインの開発方法" #: ../../rst/dev_guide/developing_api.rst:44 #: ../../rst/dev_guide/developing_inventory.rst:419 #: ../../rst/dev_guide/testing_units_modules.rst:553 msgid "`Development Mailing List `_" msgstr "`Development Mailing List `_" #: ../../rst/dev_guide/developing_api.rst:45 #: ../../rst/dev_guide/developing_inventory.rst:420 #: ../../rst/dev_guide/testing_units_modules.rst:554 msgid "Mailing list for development topics" msgstr "開発トピックのメーリングリスト" #: ../../rst/dev_guide/developing_collections.rst:6 msgid "Developing collections" msgstr "コレクションの開発" #: ../../rst/dev_guide/developing_collections.rst:8 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 `_." msgstr "コレクションは、Ansible コンテンツのディストリビューション形式です。コレクションを使用して、Playbook、ロール、モジュール、プラグインをパッケージ化および配布できます。`Ansible Galaxy `_ を介してコレクションを公開および使用できます。" #: ../../rst/dev_guide/developing_collections.rst:11 msgid "For details on how to *use* collections see :ref:`collections`." msgstr "*use* コレクションの使用方法は、「:ref:`collections`」を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:12 msgid "For the current development status of Collections and FAQ see `Ansible Collections Overview and FAQ `_." msgstr "コレクションおよび FAQ の現在の開発ステータスは、「`Ansible Collections Overview and FAQ `_」を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:21 msgid "Collection structure" msgstr "コレクション構造" #: ../../rst/dev_guide/developing_collections.rst:23 msgid "Collections follow 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.rst:49 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.rst:50 msgid "See the `ansible-collections `_ GitHub Org for examples of collection structure." msgstr "コレクション構造の例は、`ansible-collections `_ GitHub Org を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:51 msgid "Not all directories are currently in use. Those are placeholders for future features." msgstr "現在、すべてのディレクトリが使用されているわけではありません。これらは、将来の機能のプレースホルダーです。" #: ../../rst/dev_guide/developing_collections.rst:56 msgid "galaxy.yml" msgstr "galaxy.yml" #: ../../rst/dev_guide/developing_collections.rst:58 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.rst:64 msgid "docs directory" msgstr "ドキュメンテーションディレクトリー" #: ../../rst/dev_guide/developing_collections.rst:66 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`` フォルダーを使用して、ロール、コレクションが提供するロール、ロール要件などを説明します。マークダウンを使用し、サブフォルダーを追加しないでください。" #: ../../rst/dev_guide/developing_collections.rst:68 msgid "Use ``ansible-doc`` to view documentation for plugins inside a collection:" msgstr "``ansible-doc`` を使用して、コレクション内のプラグインのドキュメントを表示します。" #: ../../rst/dev_guide/developing_collections.rst:74 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.rst:76 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.rst:81 msgid "plugins directory" msgstr "プラグインディレクトリー" #: ../../rst/dev_guide/developing_collections.rst:83 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.rst:85 msgid "Vars plugins are unsupported in collections. Cache plugins may be used in collections for fact caching, but are not supported for inventory plugins." msgstr "コレクションでは、vars プラグインはサポートされていません。キャッシュプラグインはファクトキャッシュのためにコレクションで使用できますが、インベントリープラグインではサポートされていません。" #: ../../rst/dev_guide/developing_collections.rst:90 #: ../../rst/dev_guide/developing_collections.rst:639 msgid "module_utils" msgstr "module_utils" #: ../../rst/dev_guide/developing_collections.rst:92 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.rst:94 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.rst:124 msgid "Note that importing something from an ``__init__.py`` file requires using the file name:" msgstr "``__init__.py`` ファイルから何かをインポートする場合は、ファイル名を使用する必要があることに注意してください。" #: ../../rst/dev_guide/developing_collections.rst:130 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.rst:152 msgid "roles directory" msgstr "roles ディレクトリー" #: ../../rst/dev_guide/developing_collections.rst:154 msgid "Collection roles are mostly the same as existing roles, but with a couple of limitations:" msgstr "コレクションロールは既存ロールとほぼ同じですが、いくつか制限があります。" #: ../../rst/dev_guide/developing_collections.rst:156 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.rst:157 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.rst:159 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.rst:163 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.rst:167 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.rst:170 msgid "playbooks directory" msgstr "playbooks ディレクトリー" #: ../../rst/dev_guide/developing_collections.rst:172 msgid "TBD." msgstr "現在準備中です。" #: ../../rst/dev_guide/developing_collections.rst:177 msgid "tests directory" msgstr "tests ディレクトリー" #: ../../rst/dev_guide/developing_collections.rst:179 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-test` Ansible バージョン 2.9.0 以降の一部としてリリースされたユーティリティーを使用してテストされます。Ansible コレクションは Ansible 自体と同じツールを使用してテストされるため、`ansible-test` を介して、テスト用のすべての Ansible 開発者向けドキュメントは、覚えておくべき 1 つの重要な概念を使用してコレクションテストを作成するために適用できます。" #: ../../rst/dev_guide/developing_collections.rst:185 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.rst:188 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-test` を含む Ansible の安定したリリースをインストールするにはは、これらをセットアップすることが予想されるためです。" #: ../../rst/dev_guide/developing_collections.rst:202 msgid "meta directory" msgstr "meta ディレクトリー" #: ../../rst/dev_guide/developing_collections.rst:204 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.rst:206 msgid "*requires_ansible*:" msgstr "*requires_ansible*:" #: ../../rst/dev_guide/developing_collections.rst:208 msgid "The version of Ansible required to use the collection. Multiple versions can be separated with a comma." msgstr "コレクションを使用するために必要な Ansible のバージョン。複数のバージョンはコンマで区切ることができます。" #: ../../rst/dev_guide/developing_collections.rst:214 msgid "although the version is a `PEP440 Version Specifier `_ 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 バージョン指定子 `_ ですが、内部では、Ansible はプレリリースセグメントを Ansible バージョンから切り捨てることにより、PEP440 の動作から逸脱しています。これは、Ansible2.11.0b1 が ``requires_ansible: \">=2.11\"`` であるものと互換性があることを意味します。" #: ../../rst/dev_guide/developing_collections.rst:216 msgid "*plugin_routing*:" msgstr "*plugin_routing*:" #: ../../rst/dev_guide/developing_collections.rst:218 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.rst:247 msgid "*import_redirection*" msgstr "*import_redirection*" #: ../../rst/dev_guide/developing_collections.rst:249 msgid "A mapping of names for Python import statements and their redirected locations." msgstr "Python インポートステートメントの名前とそのリダイレクトされた場所のマッピング。" #: ../../rst/dev_guide/developing_collections.rst:261 msgid "Creating a collection skeleton" msgstr "コレクションスケルトンの作成" #: ../../rst/dev_guide/developing_collections.rst:263 msgid "To start a new collection:" msgstr "新規コレクションを開始するには、以下を使用します。" #: ../../rst/dev_guide/developing_collections.rst:271 msgid "Both the namespace and collection names use the same strict set of requirements. See `Galaxy namespaces `_ on the Galaxy docsite for those requirements." msgstr "名前空間とコレクション名はいずれも、同じ厳密な要件セットを使用します。これらの要件については、Galaxy ドキュメントスイートの「`Galaxy namespaces `_」で確認してください。" #: ../../rst/dev_guide/developing_collections.rst:273 msgid "Once the skeleton exists, you can populate the directories with the content you want inside the collection. See `ansible-collections `_ GitHub Org to get a better idea of what you can place inside a collection." msgstr "スケルトンが存在すると、コレクション内の内容でディレクトリーを設定できます。`ansible-collections `_ の GitHub Org で、コレクションに配置できる内容を十分に理解することができます。" #: ../../rst/dev_guide/developing_collections.rst:278 msgid "Creating collections" msgstr "コレクションの作成" #: ../../rst/dev_guide/developing_collections.rst:280 msgid "To create a collection:" msgstr "コレクションを作成するには、以下を行います。" #: ../../rst/dev_guide/developing_collections.rst:282 msgid "Create a collection skeleton with the ``collection init`` command. See :ref:`creating_collections_skeleton` above." msgstr "``collection init`` コマンドでコレクションスケルトンを作成します。上記の「:ref:`creating_collections_skeleton`」を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:283 msgid "Add your content to the collection." msgstr "コンテンツをコレクションに追加します。" #: ../../rst/dev_guide/developing_collections.rst:284 msgid "Build the collection into a collection artifact with :ref:`ansible-galaxy collection build`." msgstr ":ref:`ansible-galaxy collection build` を使用してコレクションをコレクションアーティファクトにビルドします。" #: ../../rst/dev_guide/developing_collections.rst:285 msgid "Publish the collection artifact to Galaxy with :ref:`ansible-galaxy collection publish`." msgstr ":ref:`ansible-galaxy collection publish` で構築したコレクションアーティファクトを Galaxy に公開します。" #: ../../rst/dev_guide/developing_collections.rst:287 msgid "A user can then install your collection on their systems." msgstr "これにより、ユーザーが、そのコレクションをシステムにインストールできるようになります。" #: ../../rst/dev_guide/developing_collections.rst:289 msgid "Currently the ``ansible-galaxy collection`` command implements the following sub commands:" msgstr "現在、``ansible-galaxy collection`` コマンドは以下のサブコマンドを実装します。" #: ../../rst/dev_guide/developing_collections.rst:291 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.rst:292 msgid "``build``: Create a collection artifact that can be uploaded to Galaxy or your own repository." msgstr "``build``: Galaxy または独自のリポジトリーにアップロードできるコレクションアーティファクトを作成します。" #: ../../rst/dev_guide/developing_collections.rst:293 msgid "``publish``: Publish a built collection artifact to Galaxy." msgstr "``publish``: 構築したコレクションアーティファクトを Galaxy に公開します。" #: ../../rst/dev_guide/developing_collections.rst:294 msgid "``install``: Install one or more collections." msgstr "``install``: 1 つ以上のコレクションをインストールします。" #: ../../rst/dev_guide/developing_collections.rst:296 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.rst:302 msgid "Using documentation fragments in collections" msgstr "コレクションでのドキュメントフラグメントの使用" #: ../../rst/dev_guide/developing_collections.rst:304 msgid "To include documentation fragments in your collection:" msgstr "コレクションにドキュメントフラグメントを含めるには、以下を行います。" #: ../../rst/dev_guide/developing_collections.rst:306 msgid "Create the documentation fragment: ``plugins/doc_fragments/fragment_name``." msgstr "ドキュメントフラグメントを作成します (``plugins/doc_fragments/fragment_name``)。" #: ../../rst/dev_guide/developing_collections.rst:308 msgid "Refer to the documentation fragment with its FQCN." msgstr "FQCN を含むドキュメントフラグメントを参照してください。" #: ../../rst/dev_guide/developing_collections.rst:318 msgid ":ref:`module_docs_fragments` covers the basics for documentation fragments. The `kubernetes `_ collection includes a complete example." msgstr ":ref:`module_docs_fragments` は、ドキュメントフラグメントの基本を説明します。`kubernetes `_コレクションには完全な例が含まれています。" #: ../../rst/dev_guide/developing_collections.rst:320 msgid "You can also share documentation fragments across collections with the FQCN." msgstr "また、FQCN を使用してコレクション間でドキュメントフラグメントを共有することもできます。" #: ../../rst/dev_guide/developing_collections.rst:325 msgid "Building collections" msgstr "コレクションの構築" #: ../../rst/dev_guide/developing_collections.rst:327 msgid "To build a collection, run ``ansible-galaxy collection build`` from inside the root directory of the collection:" msgstr "コレクションを構築するには、コレクションのルートディレクトリーから ``ansible-galaxy collection build`` を実行します。" #: ../../rst/dev_guide/developing_collections.rst:333 msgid "This creates a tarball of the built collection in the current directory which can be uploaded to Galaxy.::" msgstr "これにより、現在のディレクトリーに構築されたコレクションの tarball が作成されます。これは Galaxy にアップロードできます。" #: ../../rst/dev_guide/developing_collections.rst:342 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`」を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:343 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/` ディレクトリーに追加したすべてのファイルを削除します。" #: ../../rst/dev_guide/developing_collections.rst:344 msgid "The current Galaxy maximum tarball size is 2 MB." msgstr "現在の Galaxy の tarball 最大サイズは 2 MB です。" #: ../../rst/dev_guide/developing_collections.rst:347 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 にアップロードすることを目的としていますが、ターゲットシステムにコレクションをインストールするために直接使用することもできます。" #: ../../rst/dev_guide/developing_collections.rst:353 msgid "Ignoring files and folders" msgstr "ファイルやフォルダーを無視する" #: ../../rst/dev_guide/developing_collections.rst:355 msgid "By default the build step will include all the files in the collection directory in the final build artifact except for the following:" msgstr "デフォルトでは、ビルドステップには、以下を除き、最終的なビルドアーティファクト内のコレクションディレクトリーにあるすべてのファイルが含まれます。" #: ../../rst/dev_guide/developing_collections.rst:357 msgid "``galaxy.yml``" msgstr "``galaxy.yml``" #: ../../rst/dev_guide/developing_collections.rst:358 msgid "``*.pyc``" msgstr "``*.pyc``" #: ../../rst/dev_guide/developing_collections.rst:359 msgid "``*.retry``" msgstr "``*.retry``" #: ../../rst/dev_guide/developing_collections.rst:360 msgid "``tests/output``" msgstr "``tests/output``" #: ../../rst/dev_guide/developing_collections.rst:361 msgid "previously built artifacts in the root directory" msgstr "ルートディレクトリーに以前にビルドされたアーティファクト" #: ../../rst/dev_guide/developing_collections.rst:362 msgid "various version control directories like ``.git/``" msgstr "``.git/`` などのさまざまなバージョン管理ディレクトリー" #: ../../rst/dev_guide/developing_collections.rst:364 msgid "To exclude other files and folders when building the collection, you can 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 "コレクション構築時に他のファイルおよびディレクトリーを除外するには、コレクションの ``galaxy.yml`` ファイルの ``build_ignore`` キーに、ファイルグロブのようなパターンの一覧を設定します。これらのパターンはワイルドカードの一致に以下の特殊文字を使用します。" #: ../../rst/dev_guide/developing_collections.rst:368 msgid "``*``: Matches everything" msgstr "``*``: すべてに一致" #: ../../rst/dev_guide/developing_collections.rst:369 msgid "``?``: Matches any single character" msgstr "``?``: 任意の単一文字に一致します。" #: ../../rst/dev_guide/developing_collections.rst:370 msgid "``[seq]``: Matches and character in seq" msgstr "``[seq]``: シーケンス内の一致と文字" #: ../../rst/dev_guide/developing_collections.rst:371 msgid "``[!seq]``:Matches any character not in seq" msgstr "``[!seq]``: シーケンスにない文字と一致" #: ../../rst/dev_guide/developing_collections.rst:373 msgid "For example, if you wanted to exclude the :file:`sensitive` folder within the ``playbooks`` folder as well any ``.tar.gz`` archives you can set the following in your ``galaxy.yml`` file:" msgstr "たとえば、``playbooks`` ディレクトリー内の :file:`sensitive` ディレクトリーや ``.tar.gz`` アーカイブを除外する場合は、``galaxy.yml`` ファイルに以下を設定することができます。" #: ../../rst/dev_guide/developing_collections.rst:383 msgid "This feature is only supported when running ``ansible-galaxy collection build`` with Ansible 2.10 or newer." msgstr "この機能は、Ansible 2.10 以降と ``ansible-galaxy collection build`` を実行する場合に限りサポートされます。" #: ../../rst/dev_guide/developing_collections.rst:389 msgid "Trying collections locally" msgstr "ローカルでコレクションを試行" #: ../../rst/dev_guide/developing_collections.rst:391 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 がコレクションにアクセスできるようになります。" #: ../../rst/dev_guide/developing_collections.rst:399 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`` となります。" #: ../../rst/dev_guide/developing_collections.rst:403 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`」を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:405 msgid "Next, try using the local collection inside a playbook. For examples and more details see :ref:`Using collections `" msgstr "次に、Playbook 内でローカルコレクションの使用を試行します。例および詳細は、「:ref:`コレクションの使用 `」を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:410 msgid "Installing collections from a git repository" msgstr "Git リポジトリーからのコレクションのインストール" #: ../../rst/dev_guide/developing_collections.rst:412 msgid "You can also test a version of your collection in development by installing it from a git repository." msgstr "また、Git リポジトリーからインストールすることで、開発でコレクションのバージョンをテストすることもできます。" #: ../../rst/shared_snippets/installing_collections_git_repo.txt:1 msgid "You can install a collection in a git repository by providing the URI to the repository instead of a collection name or path to a ``tar.gz`` file. The collection must contain a ``galaxy.yml`` or ``MANIFEST.json`` file, which will be used to generate the would-be collection artifact data from the directory. The URI should be prefixed with ``git+`` (or with ``git@`` to use a private repository with ssh authentication) and optionally supports a comma-separated `git commit-ish `_ 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 `_ バージョン (コミットまたはタグなど) をサポートする必要があります。" #: ../../rst/shared_snippets/installing_collections_git_repo.txt:5 msgid "Embedding credentials into a git URI is not secure. Make sure to use safe auth options for security reasons. For example, use `SSH `_, `netrc `_ or `http.extraHeader `_/`url..pushInsteadOf `_ in Git config to prevent your creds from being exposed in logs." msgstr "認証情報を git URI に埋め込むことは安全ではありません。セキュリティー上の理由から、安全な認証オプションを使用してください。たとえば、Git 設定の `SSH `_、`netrc `_、または `http.extraHeader `_/`url..pushInsteadOf `_ で、クレジットがログに公開されないようにします。" #: ../../rst/shared_snippets/installing_collections_git_repo.txt:18 msgid "In a ``requirements.yml`` file, you can also use the ``type`` and ``version`` keys in addition to using the ``git+repo,version`` syntax for the collection name." msgstr "``requirements.yml`` ファイルでは、コレクション名の ``git+repo,version`` 構文を使用する他に、``type`` キーおよび ``version`` キーを使用することもできます。" #: ../../rst/shared_snippets/installing_collections_git_repo.txt:27 msgid "Git repositories can be used for collection dependencies as well. This can be helpful for local development and testing but built/published artifacts should only have dependencies on other artifacts." msgstr "git リポジトリーはコレクションの依存関係にも使用できます。これは、ローカル開発およびテストに役立ちますが、ビルド/公開されたアーティファクトには他のアーティファクトへの依存関係のみが必要です。" #: ../../rst/shared_snippets/installing_collections_git_repo.txt:34 msgid "Default repository search locations" msgstr "デフォルトのリポジトリー検索の場所" #: ../../rst/shared_snippets/installing_collections_git_repo.txt:36 msgid "There are two paths searched in a repository for collections by default." msgstr "デフォルトでは、コレクション用のリポジトリーで 2 つのパスが検索されます。" #: ../../rst/shared_snippets/installing_collections_git_repo.txt:38 msgid "The first is the ``galaxy.yml`` or ``MANIFEST.json`` file in the top level of the repository path. If the file exists it's used as the collection metadata and the individual collection will be installed." msgstr "1 つ目は、リポジトリーパスの最上位にある ``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルです。ファイルが存在する場合は、コレクションのメタデータとして使用され、個々のコレクションがインストールされます。" #: ../../rst/shared_snippets/installing_collections_git_repo.txt:49 msgid "The second is a ``galaxy.yml`` or ``MANIFEST.json`` file in each directory in the repository path (one level deep). In this scenario, each directory with a metadata file is installed as a collection." msgstr "2 つ目は、リポジトリーパス (1 レベルの深さ) の各ディレクトリーの ``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルです。ここでは、メタデータファイルが含まれる各ディレクトリーがコレクションとしてインストールされます)。" #: ../../rst/shared_snippets/installing_collections_git_repo.txt:62 msgid "Specifying the location to search for collections" msgstr "コレクションを検索する場所の指定" #: ../../rst/shared_snippets/installing_collections_git_repo.txt:64 msgid "If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate which path ansible-galaxy should inspect for metadata file(s). The path should be a directory to a collection or multiple collections (rather than the path to a ``galaxy.yml`` file or ``MANIFEST.json`` file)." msgstr "異なるリポジトリー構造がある場合や、コレクションのサブセットのみをインストールする場合は、URI の最後にフラグメントを追加して (任意のコンマ区切りバージョンの前）、ansible-galaxy がメタデータファイルを調べるパスを示すことができます。パスは、(``MANIFEST.json`` ファイルまたは ``galaxy.yml`` ファイルへのパスではなく) コレクションまたは複数のコレクションへのディレクトリーである必要があります。" #: ../../rst/dev_guide/developing_collections.rst:423 msgid "Publishing collections" msgstr "コレクションの公開" #: ../../rst/dev_guide/developing_collections.rst:425 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 `_ on the Galaxy docsite for details." msgstr "``ansible-galaxy collection publish`` コマンドまたは Galaxy UI 自体を使用して、コレクションを Galaxy に公開することができます。コレクションをアップロードするには、Galaxy に名前空間が必要です。詳細は、Galaxy のドキュメントスイートの「`Galaxy 名前空間 `_」を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:427 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 "コレクションのバージョンをアップロードしたら、そのバージョンを削除または変更することはできません。アップロードする前に、すべての情報が適切であることを確認します。" #: ../../rst/dev_guide/developing_collections.rst:432 msgid "Getting your API token" msgstr "API トークンの取得" #: ../../rst/dev_guide/developing_collections.rst:434 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``) は、コンテンツを保護するために使用されるシークレットトークン。" #: ../../rst/dev_guide/developing_collections.rst:436 msgid "To get your API token:" msgstr "API トークンを取得するには、以下を行います。" #: ../../rst/dev_guide/developing_collections.rst:438 msgid "For Galaxy, go to the `Galaxy profile preferences `_ page and click :guilabel:`API Key`." msgstr "Galaxy の場合は、`Galaxy プロファイルの設定 `_ ページに移動し、:guilabel:`API Key` をクリックします。" #: ../../rst/dev_guide/developing_collections.rst:439 msgid "For Automation Hub, go to https://cloud.redhat.com/ansible/automation-hub/token/ and click :guilabel:`Load token` from the version dropdown." msgstr "Automation Hub の場合は、https://cloud.redhat.com/ansible/automation-hub/token/ に移動し、バージョンドロップダウンの :guilabel:`Load token` をクリックします。" #: ../../rst/dev_guide/developing_collections.rst:442 msgid "Storing or using your API token" msgstr "API トークンの保存または使用" #: ../../rst/dev_guide/developing_collections.rst:444 msgid "Once you have retrieved your API token, you can store or use the token for collections in two ways:" msgstr "API トークンを取得したら、2 つの方法でコレクションにトークンを保存または使用することができます。" #: ../../rst/dev_guide/developing_collections.rst:446 msgid "Pass the token to the ``ansible-galaxy`` command using the ``--token``." msgstr "``--token`` を使用して、トークンを ``ansible-galaxy`` コマンドに渡します。" #: ../../rst/dev_guide/developing_collections.rst:447 msgid "Specify the token within a Galaxy server list in your :file:`ansible.cfg` file." msgstr ":file:`ansible.cfg` ファイルの Galaxy サーバーリスト内のトークンを指定します。" #: ../../rst/dev_guide/developing_collections.rst:450 msgid "Using the ``token`` argument" msgstr "``token`` 引数の使用" #: ../../rst/dev_guide/developing_collections.rst:452 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 `." msgstr "``--token`` 引数は、``ansible-galaxy`` コマンド (:file:`ansible.cfg` ファイルの ``--server`` 引数または :ref:`GALAXY_SERVER` 設定とともに) で使用できます。:ref:`Galaxy サーバー一覧 ` で定義されているサーバーでは、``apt-key`` を使用することはできません。" #: ../../rst/dev_guide/developing_collections.rst:460 msgid "Specify the token within a Galaxy server list" msgstr "Galaxy サーバー一覧内でトークンの指定" #: ../../rst/dev_guide/developing_collections.rst:462 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 つ以上のサーバーを構成します。サーバーごとに、トークンも構成します。" #: ../../rst/dev_guide/developing_collections.rst:474 msgid "See :ref:`galaxy_server_config` for complete details." msgstr "詳細は、「:ref:`galaxy_server_config`」を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:479 msgid "Upload using ansible-galaxy" msgstr "ansible-galaxy を使用したアップロード" #: ../../rst/dev_guide/developing_collections.rst:482 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 `." 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 クライアントの設定 `」を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:484 msgid "To upload the collection artifact with the ``ansible-galaxy`` command:" msgstr "``ansible-galaxy`` コマンドでコレクションアーティファクトをアップロードするには、以下を使用します。" #: ../../rst/dev_guide/developing_collections.rst:492 msgid "The above command assumes you have retrieved and stored your API token as part of a Galaxy server list. See :ref:`galaxy_get_token` for details." msgstr "上記のコマンドは、API トークンを取得して Galaxy サーバーリストの一部として取得し、保存していることを前提としています。詳細は「:ref:`galaxy_get_token`」を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:494 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 `_ page." msgstr "``ansible-galaxy collection publish`` コマンドは、Galaxy の Web サイトでコレクションをアップロードしているのと同様に、インポートプロセスを発生させます。コマンドは、ステータスを報告する前にインポートプロセスが完了するまで待ちます。インポート結果を待たずに続行する場合は、``--no-wait`` 引数を使用して、`My Imports `_ ページで手動でインポートの進行状況を確認します。" #: ../../rst/dev_guide/developing_collections.rst:503 msgid "Upload a collection from the Galaxy website" msgstr "Galaxy の Web サイトからコレクションをアップロードします。" #: ../../rst/dev_guide/developing_collections.rst:505 msgid "To upload your collection artifact directly on Galaxy:" msgstr "Galaxy でコレクションアーティファクトを直接アップロードするには、以下を行います。" #: ../../rst/dev_guide/developing_collections.rst:507 msgid "Go to the `My Content `_ page, and click the **Add Content** button on one of your namespaces." msgstr "`My Content `_ ページに移動し、名前空間のいずれかの **コンテンツを追加** ボタンをクリックします。" #: ../../rst/dev_guide/developing_collections.rst:508 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.rst:510 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`` ファイルのコレクションメタデータに指定された名前空間にアップロードされます。名前空間の所有者がない場合、アップロード要求は失敗します。" #: ../../rst/dev_guide/developing_collections.rst:514 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** ページにリダイレクトされます。このページには、コレクションに含まれるメタデータやコンテンツに関するエラーや警告など、インポート処理の出力が表示されます。" #: ../../rst/dev_guide/developing_collections.rst:520 msgid "Collection versions" msgstr "コレクションのバージョン" #: ../../rst/dev_guide/developing_collections.rst:522 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 のあらゆる場所に表示されるバージョンになります。ただし、ユーザーは引き続き古いバージョンをダウンロードできます。" #: ../../rst/dev_guide/developing_collections.rst:526 msgid "Collection versions use `Semantic Versioning `_ for version numbers. Please read the official documentation for details and examples. In summary:" msgstr "コレクションのバージョンは、バージョン番号に `セマンティックバージョン `_ を使用します。詳細と例は、公式ドキュメントをお読みください。要約すると、以下のようになります。" #: ../../rst/dev_guide/developing_collections.rst:528 msgid "Increment major (for example: x in `x.y.z`) version number for an incompatible API change." msgstr "互換性のない API 変更のメジャーバージョンのバージョン番号 (例: `x.y.z` の x)。" #: ../../rst/dev_guide/developing_collections.rst:529 msgid "Increment minor (for example: y in `x.y.z`) version number 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.rst:530 msgid "Increment patch (for example: z in `x.y.z`) version number for backwards compatible bug fixes." msgstr "後方互換のバグ修正向けのインクリメントパッチのバージョン番号 (例: `x.y.z` の z)。" #: ../../rst/dev_guide/developing_collections.rst:535 msgid "Migrating Ansible content to a different collection" msgstr "Ansible コンテンツのコレクションへの移行" #: ../../rst/dev_guide/developing_collections.rst:537 msgid "First, look at `Ansible Collection Checklist `_." msgstr "まず `Ansible Collection チェックリスト `_ を確認します。" #: ../../rst/dev_guide/developing_collections.rst:539 msgid "To migrate content from one collection to another, if the collections are parts of `Ansible distribution `_:" msgstr "コレクションが `Ansible ディストリビューション `_ の一部である場合は、コレクションを別のコレクションに移行するには、以下を実行します。" #: ../../rst/dev_guide/developing_collections.rst:541 msgid "Copy content from the source (old) collection to the target (new) collection." msgstr "ソース (以前の) コレクションからターゲット (新しい) コレクションにコンテンツをコピーします。" #: ../../rst/dev_guide/developing_collections.rst:542 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.rst:543 msgid "When the next major release of the old collection is prepared:" msgstr "古いコレクションの次のメジャーリリースが準備されている場合は、以下のようになります。" #: ../../rst/dev_guide/developing_collections.rst:545 msgid "remove the module/plugin from the old collection" msgstr "古いコレクションからモジュール/プラグインを削除する" #: ../../rst/dev_guide/developing_collections.rst:546 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.rst:547 msgid "remove related unit and integration tests" msgstr "関連するユニットおよびインテグレーションテストの削除" #: ../../rst/dev_guide/developing_collections.rst:548 msgid "remove specific module utils" msgstr "特定のモジュールユーティリティーの削除" #: ../../rst/dev_guide/developing_collections.rst:549 msgid "remove specific documentation fragments if there are any in the old collection" msgstr "古いコレクションにある場合は、特定のドキュメントフラグメントを削除する" #: ../../rst/dev_guide/developing_collections.rst:550 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 `_" msgstr "``removed_features`` および ``breaking_changes`` のエントリーを含む changelog フラグメントを追加します。この `プル要求 `_ で changelog フラグメントの例を確認できます。" #: ../../rst/dev_guide/developing_collections.rst:551 msgid "change ``meta/runtime.yml`` in the old collection:" msgstr "古いコレクションの ``meta/runtime.yml`` を変更します。" #: ../../rst/dev_guide/developing_collections.rst:553 msgid "add ``redirect`` to the corresponding module/plugin's entry" msgstr "対応するモジュール/プラグインのエントリーに ``redirect`` を追加" #: ../../rst/dev_guide/developing_collections.rst:554 msgid "in particular, add ``redirect`` for the removed module utils and documentation fragments if applicable" msgstr "特に、削除されたモジュールユーティリティーおよびドキュメントフラグメント (該当する場合) に ``redirect`` を追加します。" #: ../../rst/dev_guide/developing_collections.rst:555 msgid "remove ``removal_version`` from there" msgstr "そこから ``removal_version`` を削除します" #: ../../rst/dev_guide/developing_collections.rst:556 msgid "remove related entries from ``tests/sanity/ignore.txt`` files if exist" msgstr "``tests/sanity/ignore.txt`` ファイルから関連エントリーが存在する場合は削除" #: ../../rst/dev_guide/developing_collections.rst:557 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 "changelog の一部ではない削除されたコンテンツの changelog フラグメントを削除します (つまり、`changelogs/changelog.yaml` を変更せず、そのファイルに記述されているファイルを削除しないでください)。" #: ../../rst/dev_guide/developing_collections.rst:558 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.rst:560 msgid "According to the above, you need to create at least three PRs as follows:" msgstr "上記に応じて、以下のように 3 つ以上の PR を作成する必要があります。" #: ../../rst/dev_guide/developing_collections.rst:562 msgid "Create a PR against the new collection to copy the content." msgstr "新しいコレクションに対して PR を作成し、コンテンツをコピーします。" #: ../../rst/dev_guide/developing_collections.rst:563 msgid "Deprecate the module/plugin in the old collection." msgstr "古いコレクションのモジュール/プラグインが非推奨になる。" #: ../../rst/dev_guide/developing_collections.rst:564 msgid "Later create a PR against the old collection to remove the content according to the schedule." msgstr "後に、古いコレクションに対して PR を作成し、スケジュールに応じてコンテンツを削除します。" #: ../../rst/dev_guide/developing_collections.rst:568 msgid "Adding the content to the new collection" msgstr "新しいコレクションへのコンテンツの追加" #: ../../rst/dev_guide/developing_collections.rst:570 msgid "Create a PR in the new collection to:" msgstr "新しいコレクションで PR を作成し、以下を行います。" #: ../../rst/dev_guide/developing_collections.rst:572 msgid "Copy ALL the related files from the old collection." msgstr "古いコレクションから関連ファイルをすべてコピーします。" #: ../../rst/dev_guide/developing_collections.rst:573 msgid "If it is an action plugin, include the corresponding module with documentation." msgstr "アクションプラグインの場合は、ドキュメントが含まれる対応するモジュールを含めます。" #: ../../rst/dev_guide/developing_collections.rst:574 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.rst:575 msgid "Check ``meta/`` for relevant updates to ``runtime.yml`` if it exists." msgstr "``meta/`` で、``runtime.yml`` に対する関連更新が存在する場合は、それを確認します。" #: ../../rst/dev_guide/developing_collections.rst:576 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.rst:577 msgid "Review ``tests/sanity/ignore-*.txt`` entries in the old collection." msgstr "古いコレクションの ``tests/sanity/ignore-*.txt`` エントリーを確認します。" #: ../../rst/dev_guide/developing_collections.rst:578 msgid "Update ``meta/runtime.yml`` in the old collection." msgstr "古いコレクションの ``meta/runtime.yml`` を更新します。" #: ../../rst/dev_guide/developing_collections.rst:582 msgid "Removing the content from the old collection" msgstr "古いコレクションからのコンテンツの削除" #: ../../rst/dev_guide/developing_collections.rst:584 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 を作成し、この移行に関連するモジュール、module_utils、plugins、および docs_fragments を削除します。" #: ../../rst/dev_guide/developing_collections.rst:586 msgid "If you are removing an action plugin, remove the corresponding module that contains the documentation." msgstr "アクションプラグインを削除する場合は、ドキュメントが含まれる対応するモジュールを削除します。" #: ../../rst/dev_guide/developing_collections.rst:587 msgid "If you are removing a module, remove any corresponding action plugin that should stay with it." msgstr "モジュールを削除する場合は、それに対応するアクションプラグインを削除します。" #: ../../rst/dev_guide/developing_collections.rst:588 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.rst:589 msgid "Remove sanity ignore lines from ``tests/sanity/ignore\\*.txt``" msgstr "``tests/sanity/ignore\\*.txt`` から、サニティー無視の行を削除します。" #: ../../rst/dev_guide/developing_collections.rst:590 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.rst:591 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.rst:592 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.rst:593 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.rst:597 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.rst:599 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.rst:600 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.rst:604 msgid "BOTMETA.yml" msgstr "BOTMETA.yml" #: ../../rst/dev_guide/developing_collections.rst:606 msgid "The ``BOTMETA.yml``, for example in `community.general collection repository `_, is the source of truth for:" msgstr "たとえば `community.general collection repository `_ の ``BOTMETA.yml`` は、以下の信頼できるソースです。" #: ../../rst/dev_guide/developing_collections.rst:608 msgid "ansibullbot" msgstr "ansibullbot" #: ../../rst/dev_guide/developing_collections.rst:610 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.rst:612 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.rst:632 msgid "`Example PR `_" msgstr "`Example PR `_" #: ../../rst/dev_guide/developing_collections.rst:634 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.rst:635 msgid "``migrated_to:`` MUST be added for every:" msgstr "以下のすべてに ``migrated_to:`` を追加する必要があります。" #: ../../rst/dev_guide/developing_collections.rst:637 #: ../../rst/dev_guide/developing_modules_documenting.rst msgid "module" msgstr "モジュール" #: ../../rst/dev_guide/developing_collections.rst:638 msgid "plugin" msgstr "プラグイン" #: ../../rst/dev_guide/developing_collections.rst:640 msgid "contrib/inventory script" msgstr "contrib/inventory スクリプト" #: ../../rst/dev_guide/developing_collections.rst:642 msgid "You do NOT need to add ``migrated_to`` for:" msgstr "以下について ``migrated_to`` を追加する必要はありません。" #: ../../rst/dev_guide/developing_collections.rst:644 #: ../../rst/dev_guide/developing_collections.rst:668 msgid "Unit tests" msgstr "ユニットテスト" #: ../../rst/dev_guide/developing_collections.rst:645 #: ../../rst/dev_guide/developing_collections.rst:687 #: ../../rst/dev_guide/testing_integration.rst:7 msgid "Integration tests" msgstr "統合テスト" #: ../../rst/dev_guide/developing_collections.rst:646 msgid "ReStructured Text docs (anything under ``docs/docsite/rst/``)" msgstr "再構築されたテキストドキュメント (``docs/docsite/rst/`` の下すべて)" #: ../../rst/dev_guide/developing_collections.rst:647 msgid "Files that never existed in ``ansible/ansible:devel``" msgstr "``ansible/ansible:devel`` に存在しないファイル" #: ../../rst/dev_guide/developing_collections.rst:652 msgid "Testing collections" msgstr "コレクションの表示" #: ../../rst/dev_guide/developing_collections.rst:654 msgid "The main tool for testing collections is ``ansible-test``, Ansible's testing tool described in :ref:`developing_testing`. 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-base version(s) you are targeting." msgstr "コレクションをテストする主なツールは、:ref:`developing_testing` に記載されている Ansible のテストツールである ``ansible-test`` です。また、複数のコンパイルチェックと健全性チェックを実行したり、``ansible-test`` を使用してプラグイン用にユニットテストや統合テストを実行できます。コレクションをテストする場合に、使用する ansible-base バージョンをテストする際にテストすることができます。" #: ../../rst/dev_guide/developing_collections.rst:656 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 Shippable both in the ansible/ansible GitHub repository and in the large community collections such as `community.general `_ and `community.network `_. The examples below demonstrate running tests in Docker containers." msgstr "常に、コレクションのルートディレクトリーから、``ansible-test`` を実行する必要があります。特別な要件をインストールせずに Docker コンテナーの ``ansible-test`` を実行できます。Ansible チームは、ansible/ansible GitHub リポジトリーと、`community.general `_ や `community.network `_ ような大規模なコミュニティーコレクションの両方の Shippable で、このアプローチを使用します。以下ので例は、Docker コンテナーでテストを実行しています。" #: ../../rst/dev_guide/developing_collections.rst:659 msgid "Compile and sanity tests" msgstr "コンパイルとサニティーテスト" #: ../../rst/dev_guide/developing_collections.rst:661 msgid "To run all compile and sanity tests::" msgstr "すべてのコンパイルおよびサニティーテストを実行するには、以下を実行します。" #: ../../rst/dev_guide/developing_collections.rst:665 msgid "See :ref:`testing_compile` and :ref:`testing_sanity` for more information. See the :ref:`full list of sanity tests ` for details on the sanity tests and how to fix identified issues." msgstr "詳細は、:ref:`testing_compile` および :ref:`testing_sanity` を参照してください。健全性テストと、特定された問題を修正する方法は、「:ref:`健全性テストの完全リスト `」を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:670 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 `_." 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`` にテストを置きます。たとえば、`community.general のユニットテスト `_ を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:672 msgid "To run all unit tests for all supported Python versions::" msgstr "サポートされるすべての Python バージョンに対して、すべてのユニットテストを実行するには、以下のコマンドを実行します。" #: ../../rst/dev_guide/developing_collections.rst:676 msgid "To run all unit tests only for a specific Python version::" msgstr "特定の Python バージョンに対してのみ、ユニットテストをすべて実行するには、以下を実行します。" #: ../../rst/dev_guide/developing_collections.rst:680 msgid "To run only a specific unit test::" msgstr "特定のユニットテストのみを実行するには、以下を実行します。" #: ../../rst/dev_guide/developing_collections.rst:684 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.rst:689 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.rst:691 msgid "You can write two different kinds of integration tests:" msgstr "2 種類の統合テストを作成できます。" #: ../../rst/dev_guide/developing_collections.rst:693 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 "これらのテストは、他の統合テスト (通常 ``prepare_bar`` または ``setup_bar`` と呼ばれ、モジュール ``foo`` をテストするためにサービスを準備したり、``bar`` という要件をインストールしたりする) に依存して、必要なライブラリーのインストールやサーバーサービスの設定など、必要なリソースを設定することができます。" #: ../../rst/dev_guide/developing_collections.rst:694 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.rst:696 msgid "For examples, see the `integration tests in community.general `_. See also :ref:`testing_integration` for more details." msgstr "例については、「`community.general の統合テスト `_」を参照してください。詳細は、「:ref:`testing_integration`」も参照してください。" #: ../../rst/dev_guide/developing_collections.rst:698 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 `_ for all options. Use the ``default`` image mainly for platform-independent integration tests, such as those for cloud modules. The following examples use the ``centos8`` image." msgstr "統合テストは、要件のインストールや、サービスの設定、開始、および停止を行うことができるため、可能な限り、Docker コンテナーや、制限された環境で実行することが推奨されます。デフォルトでは、``ansible-test`` は複数のオペレーティングシステムの Docker イメージをサポートします。すべてのオプションは `サポート対象の docker イメージ `_ を参照してください。クラウドモジュール用などのプラットフォームに依存しない統合テストには、主に ``default`` イメージを使用します。以下の例では、``centos8`` イメージが使用されています。" #: ../../rst/dev_guide/developing_collections.rst:700 msgid "To execute all integration tests for a collection::" msgstr "特定のモジュールに対して統合テストを実行するには、次を実行します。" #: ../../rst/dev_guide/developing_collections.rst:704 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.rst:706 msgid "To execute only the integration tests in a specific directory::" msgstr "特定のディレクトリーで統合テストのみを実行するには、以下を行います。" #: ../../rst/dev_guide/developing_collections.rst:710 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.rst:715 msgid "Contributing to collections" msgstr "コレクションへの貢献" #: ../../rst/dev_guide/developing_collections.rst:717 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``)." msgstr "既存のコレクションに機能を追加する場合は、バグを修正するために使用するコレクションを変更するか、コレクションでモジュールの動作を変更して、ブランチで git リポジトリーのクローンを作成し、ブランチに変更することができます。コレクションへの変更を、Ansible のローカルチェックアウトと組み合わせることができます (``source hacking/env-setup``)。" #: ../../rst/dev_guide/developing_collections.rst:719 msgid "This section describes the process for `community.general `_. To contribute to other collections, replace the folder names ``community`` and ``general`` with the namespace and collection name of a different collection." msgstr "このセクションでは、`community.general `_ のプロセスを説明します。他のコレクションに貢献する場合は、フォルダー名 ``community`` および ``general`` を、異なるコレクションの名前空間およびコレクション名に置き換えます。" #: ../../rst/dev_guide/developing_collections.rst:721 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 `_ 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 `_ のクローンを作成するか、フォルダー ``general`` にそのディレクトリーのフォークを作成します。" #: ../../rst/dev_guide/developing_collections.rst:727 msgid "If you clone a fork, add the original repository as a remote ``upstream``::" msgstr "フォークのクローンを作成したら、元のリポジトリーをリモートの ``upstream`` として追加します。" #: ../../rst/dev_guide/developing_collections.rst:732 msgid "Now you can use 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.rst:734 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`` でこれに貢献する情報を確認してください。" #: ../../rst/dev_guide/developing_collections.rst:739 msgid "Generating changelogs for a collection" msgstr "コレクションのチェンジログの生成" #: ../../rst/dev_guide/developing_collections.rst:741 msgid "We recommend that you use the `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 `_ ツールを使用してコレクションに Ansible 互換の changelog を生成することが推奨されます。Ansibleの changelog は、このツールの出力を利用して、Ansible のリリースに含まれるすべてのコレクションを、そのリリースの 1 つの統合されたチェンジログに照合します。" #: ../../rst/dev_guide/developing_collections.rst:745 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.rst:748 msgid "Understanding antsibull-changelog" msgstr "antsibull-changelog について" #: ../../rst/dev_guide/developing_collections.rst:750 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 の changelog と互換性のある Ansible コレクションに対して changelog を作成し、更新できます。これは、Ansible リリース以前で使用される changelog ジェネレーターに対する更新です。このツールは、``breaking_changes``、``security_fixes``、および ``trivial`` の 3 つの新しい changelog フラグメントカテゴリーを追加します。このツールは、Ansible がリリースを組み合わせた ``CHANGELOG.rst`` ファイルと移植ガイドを作成するために使用する ``changelog.yaml`` ファイルも生成します。" #: ../../rst/dev_guide/developing_collections.rst:752 msgid "See :ref:`changelogs_how_to` and the `antsibull-changelog documentation `_ for complete details." msgstr "詳細は、「:ref:`changelogs_how_to`」および`antsibull-changelog ドキュメント `_ を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:756 msgid "The collection maintainers set the changelog policy for their collections. See the individual collection contributing guidelines for complete details." msgstr "コレクションのメンテナーは、コレクションに changelog ポリシーを設定します。詳細は、詳細については、個々のコレクションの貢献ガイドラインを参照してください。" #: ../../rst/dev_guide/developing_collections.rst:759 msgid "Generating changelogs" msgstr "changelog の生成" #: ../../rst/dev_guide/developing_collections.rst:761 msgid "To initialize changelog generation:" msgstr "チェンジログの生成を初期化するには、以下を実行します。" #: ../../rst/dev_guide/developing_collections.rst:763 msgid "Install ``antsibull-changelog``: :code:`pip install antsibull-changelog`." msgstr "``antsibull-changelog``: :code:`pip install antsibull-changelog` をインストールします。" #: ../../rst/dev_guide/developing_collections.rst:764 msgid "Initialize changelogs for your repository: :code:`antsibull-changelog init `." msgstr "リポジトリーの changelog を初期化します (:code:`antsibull-changelog init `)。" #: ../../rst/dev_guide/developing_collections.rst:765 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 `_ for details." msgstr "必要に応じて、``changelogs/config.yaml`` ファイルを編集して、生成された changelog の ``.rst`` ファイルまたはその他のオプションをカスタマイズします。詳細は、「`コレクションの changelog のブートストラップ `ブートストラップ_」を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:767 msgid "To generate changelogs from the changelog fragments you created:" msgstr "作成した changelog フラグメントからチェンジログを生成するには、以下を実行します。" #: ../../rst/dev_guide/developing_collections.rst:769 msgid "Optionally, validate your changelog fragments: :code:`antsibull-changelog lint`." msgstr "必要に応じて、チェンジログフラグメント (:code:`antsibull-changelog lint`) を検証します。" #: ../../rst/dev_guide/developing_collections.rst:770 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.rst:774 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.rst:778 msgid "Porting Guide entries" msgstr "移植ガイドエントリー" #: ../../rst/dev_guide/developing_collections.rst:780 msgid "The following changelog fragment categories are consumed by the Ansible changelog generator into the Ansible Porting Guide:" msgstr "以下の changelog フラグメントカテゴリーは、Ansible changelog ジェネレーターが Ansible 移植ガイドに使用されます。" #: ../../rst/dev_guide/developing_collections.rst:782 msgid "``major_changes``" msgstr "``major_changes``" #: ../../rst/dev_guide/developing_collections.rst:783 msgid "``breaking_changes``" msgstr "``breaking_changes``" #: ../../rst/dev_guide/developing_collections.rst:784 msgid "``deprecated_features``" msgstr "``deprecated_features``" #: ../../rst/dev_guide/developing_collections.rst:785 msgid "``removed_features``" msgstr "``removed_features``" #: ../../rst/dev_guide/developing_collections.rst:788 msgid "Including collection changelogs into Ansible" msgstr "Ansible へのコレクション変更ログの追加" #: ../../rst/dev_guide/developing_collections.rst:791 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 つのオプションのいずれかを使用して、Ansible リリースの changelog に changelog を追加します。" #: ../../rst/dev_guide/developing_collections.rst:793 msgid "Use the ``antsibull-changelog`` tool." msgstr "``antsibull-changelog`` ツールの使用" #: ../../rst/dev_guide/developing_collections.rst:795 msgid "If are not using this tool, include the properly formatted ``changelog.yaml`` file into your collection. See the `changelog.yaml format `_ for details." msgstr "このツールを使用していない場合は、適切にフォーマットされた ``changelog.yaml`` ファイルをコレクションに追加します。詳細は、「`changelog.yaml 形式 `_」を参照してください。" #: ../../rst/dev_guide/developing_collections.rst:797 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/ で開いて、任意の形式で独自の changelog またはリリースノートへのリンクを追加します。" #: ../../rst/dev_guide/developing_collections.rst:801 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 は changelog の詳細を Galaxy からプルし、changelog を今後の Ansible リリースに含まれる Galaxy のコレクションバージョンに追加する必要があります。" #: ../../rst/dev_guide/developing_collections.rst:807 msgid ":ref:`collections_galaxy_meta`" msgstr ":ref:`collections_galaxy_meta`" #: ../../rst/dev_guide/developing_collections.rst:808 msgid "Understand the collections metadata structure." msgstr "コレクションのメタデータ構造を理解します。" #: ../../rst/dev_guide/developing_core.rst:3 msgid "Developing ``ansible-base``" msgstr "``ansible-base`` の開発" #: ../../rst/dev_guide/developing_core.rst:5 msgid "Although ``ansible-base`` (the code hosted in the `ansible/ansible repository `_ 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-base`` work together." msgstr "``ansible-base`` (GitHub の `ansible/ansible repository `_ でホストされるコード) には、Playbook ディレクティブまたは設定を介してスワップできるプラグインが含まれていますが、モジュール化されないコードが多くあります。また、``ansible-base`` の一部が連携する方法に関するドキュメントです。" #: ../../rst/dev_guide/developing_core.rst:14 #: ../../rst/dev_guide/developing_inventory.rst:411 #: ../../rst/dev_guide/developing_plugins.rst:492 msgid ":ref:`developing_api`" msgstr ":ref:`developing_api`" #: ../../rst/dev_guide/developing_core.rst:15 #: ../../rst/dev_guide/developing_plugins.rst:493 msgid "Learn about the Python API for task execution" msgstr "タスク実行用の Python API について" #: ../../rst/dev_guide/developing_core.rst:17 msgid "Learn about developing plugins" msgstr "プラグインの開発について" #: ../../rst/dev_guide/developing_core.rst:21 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 `. 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:`インベントリープラグイン ` を使用して、クラウドソースを含む動的ソースからインベントリー情報をプルすることができます。インベントリー情報のプル方法の詳細は、「: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 ` 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 ` instead, you can leverage the Ansible codebase and add these common features automatically." msgstr "以前のバージョンでは、適切な引数で呼び出されたときに正しい形式で JSON を出力できるスクリプトやプログラムを作成する必要がありました。:ref:`スクリプトインベントリープラグイン ` を通じて後方互換性を確保しており、使用するプログラミング言語にも制限がないため、インベントリースクリプトを使用したり書いたりすることができます。ただし、スクリプトを書く場合は、キャッシュ、設定管理、動的な変数やグループの構成など、いくつかの機能を自分で実装する必要があります。代わりに:ref:`インベントリープラグイン ` を使用すれば、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 `" msgstr ":ref:`host list `" #: ../../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 `" msgstr ":ref:`yaml `" #: ../../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 `" msgstr ":ref:`constructed `" #: ../../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 `" msgstr ":ref:`ini `" #: ../../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 `" msgstr ":ref:`virtualbox `" #: ../../rst/dev_guide/developing_inventory.rst:42 msgid ":ref:`script plugin `" msgstr ":ref:`script plugin `" #: ../../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:314 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 プラグインは設定済みのキャッシュプラグインを使用してデータを保存および取得し、コストのかかる外部呼び出しを回避することもできます。" #: ../../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 `, 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 . should be accepted. All valid extensions should be documented in the plugin description." msgstr "上記の例では、:ref:`virtualbox インベントリープラグイン ` からは、有効な YAML ファイルの使用を試みないように、特定のファイル名パターンの画面があります。ここに任意のタイプの条件を追加できますが、最も一般的なものは「拡張子の一致」です。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 ` plugin:" msgstr "以下は、「ファイル」を使用せず、:ref:`host list ` プラグインからインベントリソース文字列自体を使用する別の例です。" #: ../../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 `_." msgstr "インベントリープラグインの実装方法の例は、ソースコード (`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:276 msgid "Common format for inventory sources" msgstr "インベントリーソースの共通形式" #: ../../rst/dev_guide/developing_inventory.rst:278 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:285 msgid "The 'auto' plugin" msgstr "「auto」プラグイン" #: ../../rst/dev_guide/developing_inventory.rst:287 msgid "From Ansible 2.5 onwards, we include the :ref:`auto inventory plugin ` 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 ` を追加し、これをデフォルトで有効化します。標準設定ファイルの ``plugin`` フィールドがインベントリープラグインの名前と一致する場合、``auto`` インベントリープラグインはプラグインを読み込みます。「auto」プラグインは、設定を更新せずにプラグインを簡単に使用できます。" #: ../../rst/dev_guide/developing_inventory.rst:294 msgid "Inventory scripts" msgstr "インベントリースクリプト" #: ../../rst/dev_guide/developing_inventory.rst:296 msgid "Even though we now have inventory plugins, we still support inventory scripts, not only for backwards compatibility but also to allow users to leverage other programming languages." msgstr "インベントリープラグインはそのままですが、後方互換性だけでなく、ユーザーが他のプログラミング言語を使用できるように、引き続きインベントリースクリプトをサポートします。" #: ../../rst/dev_guide/developing_inventory.rst:302 msgid "Inventory script conventions" msgstr "インベントリースクリプトの規則" #: ../../rst/dev_guide/developing_inventory.rst:304 msgid "Inventory scripts must accept the ``--list`` and ``--host `` 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 `` を受け入れる必要があります。他の引数は設定できますが、Ansible はそれらを使用しません。このような引数は、スクリプトを直接実行するのに役立つ場合があります。" #: ../../rst/dev_guide/developing_inventory.rst:307 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 でエンコードされたハッシュまたはディクショナリーを出力する必要があります。各グループの値は、各ホスト、子グループ、および潜在的なグループ変数の一覧を含むハッシュまたはディクショナリーにする必要があります。" #: ../../rst/dev_guide/developing_inventory.rst:329 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:331 msgid "When called with the argument ``--host `` (where 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 `` ( は上述のホスト) で呼び出されると、スクリプトは空の JSON ハッシュ/ディクショナリーか、テンプレートや Playbook で利用できるようにするための変数のハッシュ/ディクショナリーを出力しなければなりません。たとえば、以下のようになります。" #: ../../rst/dev_guide/developing_inventory.rst:339 msgid "Printing variables is optional. If the script does not print variables, it should print an empty hash or dictionary." msgstr "変数の出力は任意です。スクリプトが変数を出力しない場合は、空のハッシュまたはディクショナリーを出力する必要があります。" #: ../../rst/dev_guide/developing_inventory.rst:344 msgid "Tuning the external inventory script" msgstr "外部インベントリースクリプトのチューニング" #: ../../rst/dev_guide/developing_inventory.rst:348 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:350 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:352 msgid "The data to be added to the top-level JSON dictionary looks like this::" msgstr "トップレベルの JSON ディクショナリーに追加するデータは次のようになります。" #: ../../rst/dev_guide/developing_inventory.rst:371 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`` dictionary. For example::" msgstr "Ansible が ``--host`` でインベントリーを呼び出すのを防ぐために ``_meta`` を使用する要件を満たすには、少なくとも空の ``hostvars`` ディクショナリーで ``_meta`` を埋めなければなりません。以下に例を示します。" #: ../../rst/dev_guide/developing_inventory.rst:387 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:407 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:412 msgid "Python API to Playbooks and Ad Hoc Task Execution" msgstr "Playbook およびアドホックタスク実行のための Python API" #: ../../rst/dev_guide/developing_inventory.rst:414 msgid "Get started with developing a module" msgstr "モジュールの開発を始める" #: ../../rst/dev_guide/developing_inventory.rst:417 msgid "`Ansible Tower `_" msgstr "`Ansible Tower `_" #: ../../rst/dev_guide/developing_inventory.rst:418 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 "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 でロールを使用している場合は、認識せずにローカルモジュールとプラグインをすでに使用していることになります。" #: ../../rst/dev_guide/developing_locally.rst:10 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` トピックに移動してから、このページに戻り、ローカルで追加する方法を説明します。" #: ../../rst/dev_guide/developing_locally.rst:12 msgid "Extending Ansible with local modules and plugins offers lots of shortcuts such as:" msgstr "ローカルのモジュールおよびプラグインで Ansible を拡張すると、以下のようなショートカットが多数利用できるようになります。" #: ../../rst/dev_guide/developing_locally.rst:14 msgid "You can copy other people's modules and plugins." msgstr "他のユーザーのモジュールおよびプラグインをコピーできます。" #: ../../rst/dev_guide/developing_locally.rst:15 msgid "When writing a new module, you can choose any programming language you like." msgstr "新しいモジュールを作成する場合は、任意のプログラミング言語を選択できます。" #: ../../rst/dev_guide/developing_locally.rst:16 msgid "You do not have to clone any repositories." msgstr "リポジトリーのクローンを作成する必要はありません。" #: ../../rst/dev_guide/developing_locally.rst:17 msgid "You do not have to open a pull request." msgstr "プルリクエストを開く必要はありません。" #: ../../rst/dev_guide/developing_locally.rst:18 msgid "You do not have to add tests (though we recommend that you do!)." msgstr "テストを追加する必要はありません (ただし、この操作を推奨しています)。" #: ../../rst/dev_guide/developing_locally.rst:20 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 が検出して使用するようにローカルモジュールまたはプラグインを保存するには、適切なディレクトリーにモジュールまたはプラグインを追加します (ディレクトリーは、本トピックの後半で指定されています)。" #: ../../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 local functionality to Ansible, you might wonder whether you need a module or a plugin. Here is a quick overview to help you decide between the two:" 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." msgstr "モジュールは、Ansible API、:command:`ansible` コマンド、または :command:`ansible-playbook` コマンドで使用できる再利用可能なスタンドアロンスクリプトです。モジュールは、定義されたインターフェースを提供します。各モジュールは引数を受け入れ、終了する前に JSON 文字列を stdout に出力して Ansible に情報を返します。モジュールは、別のプロセスでターゲットシステム (通常はリモートシステム上) で実行されます。" #: ../../rst/dev_guide/developing_locally.rst:32 msgid ":ref:`Plugins ` augment 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:`プラグイン ` は、Ansible のコア機能を拡張し、``/usr/bin/ansible`` プロセス内のコントロールノードで実行します。する。プラグインは、Ansible のコア機能のオプションおよび拡張機能 (データの変換、ログ出力、インベントリーへの接続など) を提供します。" #: ../../rst/dev_guide/developing_locally.rst:37 msgid "Adding a module locally" msgstr "モジュールをローカルで追加" #: ../../rst/dev_guide/developing_locally.rst:38 msgid "Ansible automatically loads all executable files found in certain directories as modules." msgstr "Ansible は、特定のディレクトリーにある実行可能ファイルをすべてモジュールとして自動的に読み込みます。" #: ../../rst/dev_guide/developing_locally.rst:40 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`` を使用します。" #: ../../rst/dev_guide/developing_locally.rst:42 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 およびロールで使用できるようにするには、それらを以下のいずれかの場所に追加します。" #: ../../rst/dev_guide/developing_locally.rst:44 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``のようにコロンで区切った一覧)" #: ../../rst/dev_guide/developing_locally.rst:45 msgid "``~/.ansible/plugins/modules/``" msgstr "``~/.ansible/plugins/modules/``" #: ../../rst/dev_guide/developing_locally.rst:46 msgid "``/usr/share/ansible/plugins/modules/``" msgstr "``/usr/share/ansible/plugins/modules/``" #: ../../rst/dev_guide/developing_locally.rst:48 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:50 msgid "To confirm that ``my_custom_module`` is available:" msgstr "``my_custom_module`` が利用できることを確認するには、以下を行います。" #: ../../rst/dev_guide/developing_locally.rst:52 msgid "type ``ansible localhost -m my_custom_module``. You should see the output for that module." msgstr "``ansible localhost -m my_custom_module`` を入力します。このモジュールの出力が表示されるはずです。" #: ../../rst/dev_guide/developing_locally.rst:54 msgid "or" msgstr "または" #: ../../rst/dev_guide/developing_locally.rst:56 msgid "type ``ansible-doc -t module my_custom_module``. You should see the documentation for that module." msgstr "``ansible-doc -t module my_custom_module`` を入力します。そのモジュールのドキュメントが表示されるはずです。" #: ../../rst/dev_guide/developing_locally.rst:60 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:62 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 でのみローカルモジュールを使用する場合、または単一のロールでのみローカルモジュールを使用する場合は、以下のいずれかの場所にロードします。" #: ../../rst/dev_guide/developing_locally.rst:64 msgid "In a selected playbook or playbooks: Store the module in a subdirectory called ``library`` in the directory that contains those playbooks." msgstr "選択した Playbook で、それらの Playbook が含まれるディレクトリーの ``library`` という名前のサブディレクトリーにモジュールを保存します。" #: ../../rst/dev_guide/developing_locally.rst:65 msgid "In a single role: Store the module in a subdirectory called ``library`` within that role." msgstr "単一のロール: そのロール内の ``library`` という名前のサブディレクトリーにモジュールを保存します。" #: ../../rst/dev_guide/developing_locally.rst:71 msgid "Adding a plugin locally" msgstr "プラグインをローカルで追加" #: ../../rst/dev_guide/developing_locally.rst:72 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 はプラグインも自動的にロードし、プラグインのタイプに対して名前が付けられたディレクトリーとは別に、各タイプのプラグインを読み込みます。プラグインディレクトリー名の全一覧を以下に示します。" #: ../../rst/dev_guide/developing_locally.rst:74 msgid "action_plugins*" msgstr "action_plugins*" #: ../../rst/dev_guide/developing_locally.rst:75 msgid "cache_plugins" msgstr "cache_plugins" #: ../../rst/dev_guide/developing_locally.rst:76 msgid "callback_plugins" msgstr "callback_plugins" #: ../../rst/dev_guide/developing_locally.rst:77 msgid "connection_plugins" msgstr "connection_plugins" #: ../../rst/dev_guide/developing_locally.rst:78 msgid "filter_plugins*" msgstr "filter_plugins*" #: ../../rst/dev_guide/developing_locally.rst:79 msgid "inventory_plugins" msgstr "inventory_plugins" #: ../../rst/dev_guide/developing_locally.rst:80 msgid "lookup_plugins" msgstr "lookup_plugins" #: ../../rst/dev_guide/developing_locally.rst:81 msgid "shell_plugins" msgstr "shell_plugins" #: ../../rst/dev_guide/developing_locally.rst:82 msgid "strategy_plugins" msgstr "strategy_plugins" #: ../../rst/dev_guide/developing_locally.rst:83 msgid "test_plugins*" msgstr "test_plugins*" #: ../../rst/dev_guide/developing_locally.rst:84 msgid "vars_plugins" msgstr "vars_plugins" #: ../../rst/dev_guide/developing_locally.rst:88 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 "プラグインを追加して、それらが使用できることを確認すると、上記のアスタリスク (*) のマークが付いたものを除き、すべてのプラグインのドキュメントを表示できます。" #: ../../rst/dev_guide/developing_locally.rst:90 msgid "To load your local plugins automatically, add them in any of these locations:" msgstr "ローカルプラグインを自動的に読み込むには、以下のいずれかの場所に追加します。" #: ../../rst/dev_guide/developing_locally.rst:92 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`` のようにコロンで区切った一覧を取ります。" #: ../../rst/dev_guide/developing_locally.rst:93 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``)" #: ../../rst/dev_guide/developing_locally.rst:94 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``)" #: ../../rst/dev_guide/developing_locally.rst:96 msgid "After your plugin file is in one of these locations, Ansible loads it and you can use it in any local module, task, playbook, or role. Alternatively, you can edit your ``ansible.cfg`` file to add directories that contain local plugins. For details about adding directories of local plugins, see :ref:`ansible_configuration_settings`." msgstr "プラグインファイルがこれらの場所のいずれかに置かれたら、Ansible が読み込み、ローカルモジュール、タスク、Playbook、またはロールで使用することができます。``ansible.cfg`` ファイルを編集してローカルプラグインを含むディレクトリーを追加できます。ローカルプラグインのディレクトリーを追加する方法については、:ref:`ansible_configuration_settings` を参照してください。" #: ../../rst/dev_guide/developing_locally.rst:98 msgid "To confirm that ``plugins/plugin_type/my_custom_plugin`` is available:" msgstr "``plugins/plugin_type/my_custom_plugin`` が利用できることを確認するには、以下を行います。" #: ../../rst/dev_guide/developing_locally.rst:100 msgid "type ``ansible-doc -t 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 my_custom_lookup_plugin`` を入力します (例: ``ansible-doc -t lookup my_custom_lookup_plugin``)。そのプラグインに関するドキュメントを確認してください。これは上記のリストで ``*`` のマークが付いたもの以外のすべてのプラグインタイプで機能します。詳細は「:ref:`ansible-doc`」を参照してください。" #: ../../rst/dev_guide/developing_locally.rst:102 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 でのみローカルプラグインを使用する場合、または単一のロールでのみローカルプラグインを使用する場合は、以下のいずれかの場所に読み込みます。" #: ../../rst/dev_guide/developing_locally.rst:104 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``) のサブディレクトリーにプラグインを保存します。" #: ../../rst/dev_guide/developing_locally.rst:105 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``) のサブディレクトリーにプラグインを保存します。ロールの一部として提供されると、ロールが実行されるとすぐにプラグインが利用可能になります。" #: ../../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:15 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 ` derived from the active configuration." msgstr "``ansible.module_utils`` 名前空間は単純な Python パッケージではありません。これは、インポートを抽出し、アクティブな設定から派生する :ref:`検索パス ` に対して一致する名前空間を解決することで、各タスク呼び出し用に動的に構築されます。" #: ../../rst/dev_guide/developing_module_utilities.rst:20 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:25 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 `." msgstr "``ansible-playbook`` を実行すると、Ansible は :ref:`Ansible search path ` で定義されている順序でローカルの ``module_utils`` ディレクトリーのファイルを ``ansible.module_utils`` 名前空間にマージします。" #: ../../rst/dev_guide/developing_module_utilities.rst:28 msgid "Naming and finding module utilities" msgstr "モジュールユーティリティーの命名および検索" #: ../../rst/dev_guide/developing_module_utilities.rst:30 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:32 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:33 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:34 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:36 msgid "Following this pattern with your own module utilities makes everything easy to find and use." msgstr "このパターンを独自のモジュールユーティリティーで行うと、あらゆるものを見つけ、使用することが容易になります。" #: ../../rst/dev_guide/developing_module_utilities.rst:41 msgid "Standard module utilities" msgstr "標準のモジュールユーティリティー" #: ../../rst/dev_guide/developing_module_utilities.rst:43 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 `_." msgstr "Ansible には、``module_utils`` ファイルの広範なライブラリーが含まれています。モジュールユーティリティーのソースコードは、メインの Ansible パス下の ``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 以降を持つ ``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/developing_module_utilities.rst:47 msgid "``api.py`` - Supports generic API modules" msgstr "``api.py`` - 汎用 API モジュールのサポート" #: ../../rst/dev_guide/developing_module_utilities.rst:48 msgid "``basic.py`` - General definitions and helper utilities for Ansible modules" msgstr "``basic.py`` - Ansible モジュールの一般的な定義およびヘルパーユーティリティー。" #: ../../rst/dev_guide/developing_module_utilities.rst:49 msgid "``common/dict_transformations.py`` - Helper functions for dictionary transformations" msgstr "``common/dict_transformations.py`` - ディクショナリー変換のヘルパー関数。" #: ../../rst/dev_guide/developing_module_utilities.rst:50 msgid "``common/file.py`` - Helper functions for working with files" msgstr "``common/file.py`` - ファイルを操作するヘルパー関数" #: ../../rst/dev_guide/developing_module_utilities.rst:51 msgid "``common/text/`` - Helper functions for converting and formatting text" msgstr "``common/text/`` - テキスト変換およびフォーマットを行うためのヘルパー関数" #: ../../rst/dev_guide/developing_module_utilities.rst:52 msgid "``common/parameters.py`` - Helper functions for dealing with module parameters" msgstr "``common/parameters.py`` - モジュールパラメーターを処理するヘルパー関数" #: ../../rst/dev_guide/developing_module_utilities.rst:53 msgid "``common/sys_info.py`` - Functions for getting distribution and platform information" msgstr "``common/sys_info.py`` - ディストリビューションおよびプラットフォーム情報を取得する機能。" #: ../../rst/dev_guide/developing_module_utilities.rst:54 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:55 msgid "``facts/`` - Directory of utilities for modules that return facts. See `PR 23012 `_ for more information" msgstr "``facts/`` - 詳細は、`PR 23012 `_ を参照してください。" #: ../../rst/dev_guide/developing_module_utilities.rst:56 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:57 msgid "``powershell/`` - Directory of definitions and helper functions for Windows PowerShell modules" msgstr "``powershell/`` - Windows PowerShell モジュールの定義およびヘルパー関数のディレクトリー。" #: ../../rst/dev_guide/developing_module_utilities.rst:58 msgid "``pycompat24.py`` - Exception workaround for Python 2.4" msgstr "``pycompat24.py`` - Python 2.4 の例外回避策" #: ../../rst/dev_guide/developing_module_utilities.rst:59 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:60 msgid "``six/__init__.py`` - Bundled copy of the `Six Python library `_ to aid in writing code compatible with both Python 2 and Python 3" msgstr "``six/__init__.py`` - Python 2 と Python 3 の両方と互換性のあるコードを書き込む際に助けとなる `Six Python ライブラリー `_ のバンドルコピー。" #: ../../rst/dev_guide/developing_module_utilities.rst:61 msgid "``splitter.py`` - String splitting and manipulation utilities for working with Jinja2 templates" msgstr "``splitter.py`` - Jinja2 テンプレートを使用する文字列分割および操作ユーティリティー。" #: ../../rst/dev_guide/developing_module_utilities.rst:62 msgid "``urls.py`` - Utilities for working with http and https requests" msgstr "``urls.py`` - http および https リクエストを操作するユーティリティー。" #: ../../rst/dev_guide/developing_module_utilities.rst:64 msgid "Several commonly-used utilities migrated to collections in Ansible 2.10, including:" msgstr "一般的に使用されるいくつかのユーティリティーは、Ansible 2.10 では以下のようなコレクションに移行されています。" #: ../../rst/dev_guide/developing_module_utilities.rst:66 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:67 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:69 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 ` or `Ansible Galaxy `_ to see if an existing module does what you need." msgstr "既存のモジュールは必要な機能に対応できます。Ansible コレクションには、数千のモジュールが含まれています。:ref:`同梱されるコレクションの一覧 ` または `Ansible Galaxy `_ を検索すると、既存のモジュールが必要なモジュールかどうかが分かります。" #: ../../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 `." msgstr "アクションプラグインは、必要な機能を取得する最善の方法となるでしょう。アクションプラグインは、管理ノードではなくコントロールノードで実行され、その機能はすべてのモジュールで利用できます。プラグインの開発に関する詳細は、「:ref:`プラグインの開発ページ`」を参照してください。" #: ../../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`." msgstr "既存のモジュールの組み合わせによって、希望の機能に対応できる可能性があります。このタイプのユースケースにロールを作成することができます。:ref:`ロールのドキュメント` を確認してください。" #: ../../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`." msgstr "1 つのモジュールでは、この機能が大きすぎる可能性があります。Ansible を新しいクラウドプロバイダー、データベース、またはネットワークプラットフォームに接続する場合は、:ref:`新しいコレクションの開発` が必要になる場合があります。" #: ../../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 `." msgstr ":ref:`新しいモジュールを使用開始` したいです。" #: ../../rst/dev_guide/developing_modules.rst:35 msgid "I want to review :ref:`tips and conventions for developing good modules `." msgstr ":ref:`良質なモジュールを開発するためのヒントおよび規約 ` を確認します。" #: ../../rst/dev_guide/developing_modules.rst:36 msgid "I want to :ref:`write a Windows module `." msgstr ":ref:`Windows モジュールを作成 ` したいです。" #: ../../rst/dev_guide/developing_modules.rst:37 msgid "I want :ref:`an overview of Ansible's architecture `." msgstr ":ref:`Ansible のアーキテクチャーの概要 ` が必要です。" #: ../../rst/dev_guide/developing_modules.rst:38 msgid "I want to :ref:`document my module `." msgstr ":ref:`作成したモジュールをドキュメント化 ` したいです。" #: ../../rst/dev_guide/developing_modules.rst:39 msgid "I want to :ref:`contribute my module back to Ansible Core `." msgstr ":ref:`作成したモジュールを Ansible Core に貢献 ` したいです。" #: ../../rst/dev_guide/developing_modules.rst:40 msgid "I want to :ref:`add unit and integration tests to my module `." msgstr ":ref:`作成したモジュールに単体テストおよび統合テストを追加 ` したいです。" #: ../../rst/dev_guide/developing_modules.rst:41 msgid "I want to :ref:`add Python 3 support to my module `." msgstr ":ref:`作成したモジュールに Python 3 サポートを追加 ` したいです。" #: ../../rst/dev_guide/developing_modules.rst:42 msgid "I want to :ref:`write multiple modules `." msgstr ":ref:`複数モジュールを作成 ` したいです。" #: ../../rst/dev_guide/developing_modules.rst:46 #: ../../rst/dev_guide/developing_plugins.rst:490 msgid ":ref:`list_of_collections`" msgstr ":ref:`list_of_collections`" #: ../../rst/dev_guide/developing_modules.rst:47 #: ../../rst/dev_guide/developing_plugins.rst:491 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 ` at all." msgstr "特に、既存の Ansible Collection にモジュールを提供する場合は、各モジュールに十分なロジックと機能が含まれていることを確認してください。ただし、多すぎないようにしてください。これらのガイドラインが紛らわしいと思われる場合は、:ref:`モジュールの記述が本当に必要かどうか ` を検討してください。" #: ../../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 ` that interact with smaller individual pieces of the API." msgstr "モジュールは、リソースと対話するためのロジックを多数組み込む必要があります。複雑な API に関連した軽量ラッパーにより、ユーザーは Playbook に非常に多くのロジックをオフロードします。Ansible を複雑な API に接続する場合は、より複雑な API と対話する :ref:`複数のモジュールを作成 ` する必要があります。" #: ../../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``、もしくはユーザーに出力される可能性があるものはなんでも受け入れる必要がります。Ansible Module の一般的なコードは、``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-base``." msgstr "各モジュールは 1 つのファイルにまとめて自己完結させる必要があり、``ansible-base`` で自動転送できるようにします。" #: ../../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-base`` from importing your module." msgstr "モジュール名は、単語の区切り文字として、ハイフンやスペースの代わりにアンダースコアを使用する必要があります。ハイフンやスペースを使用すると、``ansible-base`` がモジュールをインポートできなくなります。" #: ../../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 or tower); do not try to build it into modules." msgstr "キャッシュを作成しないでください。Ansible は中央のサーバーや権限を持たないように設計されているため、さまざまなパーミッション、オプション、場所を指定して実行しないことを保証することはできません。中央の権限が必要な場合は、それを Ansible の上に置いてください (例: bastion/cm/ci サーバーまたは Tower を使用)。それをモジュールには組み込まないでください。" #: ../../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 ` 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:`ユーティリティー ` を提供します。また、複数のモジュールに適用されるドキュメントフラグメントを作成することもできます。" #: ../../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 モジュールのインポートにはワイルドカード (*) を使用しないでください。代わりに、インポートする関数を一覧表示してください (例: ``some.other_python_module.basic からの 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 unparseable 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 `_ library. Basic python types (strings, int, dicts, lists, and so on) are serializable." msgstr "Python の標準の `JSON エンコーダーおよびデコーダー ` ライブラリーで、戻り値を 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` so other modules can access them." msgstr "他のモジュールがそれらにアクセスできるように、:ref:`結果ディクショナリー` の ``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__USERNAME` to avoid conflicts between modules." msgstr "モジュール固有の環境変数を使用します。たとえば、``module_utils.urls.fetch_url()`` での基本的な認証に ``module_utils.api`` のヘルパーを使用し、デフォルト値を環境変数に依存している場合は、モジュール間の競合を回避するために :code:`API__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:163 msgid "Follow additional guidelines that apply to families of modules if applicable. For example, AWS modules should follow the :ref:`Amazon development checklist `." msgstr "該当する場合は、モジュールのファミリーに適用される追加のガイドラインに従います。たとえば、AWS モジュールは :ref:`Amazon development checklist ` に従う必要があります。" #: ../../rst/dev_guide/developing_modules_best_practices.rst:167 msgid "Module Security" msgstr "モジュールのセキュリティー" #: ../../rst/dev_guide/developing_modules_best_practices.rst:169 msgid "Avoid passing user input from the shell." msgstr "シェルからユーザー入力を渡さないようにします。" #: ../../rst/dev_guide/developing_modules_best_practices.rst:170 msgid "Always check return codes." msgstr "常に戻りコードを確認してください。" #: ../../rst/dev_guide/developing_modules_best_practices.rst:171 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:172 msgid "Avoid using the shell unless absolutely necessary." msgstr "絶対に必要な場合を除き、シェルは使用しないでください。" #: ../../rst/dev_guide/developing_modules_best_practices.rst:173 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:174 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:175 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:176 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 `." msgstr "既存のコレクションにモジュールを提供する場合は、コミュニティーの目的の要件と主体的な要件を満たす必要があります。以下の詳細を読み、「:ref:`モジュール開発のヒント `」も確認してください。" #: ../../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 `, embed modules in roles on Galaxy or simply share copies of your module code for :ref:`local use `." msgstr "特定のコレクションで許可されるモジュールは、PyPI のすべての Ansible リリースに含まれます。ただし、これらのコレクションのいずれかに貢献することが、モジュールを配布する唯一の方法ではありません。:ref:`独自のコレクションの作成 ` は、Galaxy のロールにモジュールコードのコピーを埋め込んだり、:ref:`ローカルでの使用 ` 用にモジュールコードのコピーを共有することもできます。" #: ../../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 `" msgstr "適切な :ref:`Python 3 構文 ` を使用します。" #: ../../rst/dev_guide/developing_modules_checklist.rst:21 msgid "follow `PEP 8 `_ Python style conventions - see :ref:`testing_pep8` for more information" msgstr "`PEP 8 `_ 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 `, which applies to all contributions" msgstr "すべての貢献に適用される :ref:`ライセンス合意 ` を理解します。" #: ../../rst/dev_guide/developing_modules_checklist.rst:24 msgid "conform to Ansible's :ref:`formatting and documentation ` standards" msgstr "Ansible の :ref:`formatting and documentation ` 標準規格に準拠しています。" #: ../../rst/dev_guide/developing_modules_checklist.rst:25 msgid "include comprehensive :ref:`tests ` for your module" msgstr "モジュールに包括的な :ref:`tests ` を含めます。" #: ../../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 ` if possible" msgstr "可能な場合は :ref:`check_mode ` をサポートします。" #: ../../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 ``_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 "モジュールの名前が ``_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 `Ansible's IRC chat channel `_ or the `Ansible development mailing list `_." msgstr "PR/提案を送信する前に、お使いのモジュールがこれらの要件を満たしていることを確認してください。ご質問がある場合は、`Ansible の IRC チャットチャンネル `_ または `Ansible 開発メーリングリスト `_ までお問い合わせください。" #: ../../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 `." msgstr "モジュールがこれらの目的の要件を満たす場合は、コレクションのメンテナーが、明確、簡潔、安全であり、維持が可能であると考えるコードを確認します。モジュールが優れたユーザーエクスペリエンスを提供し、有用なエラーメッセージ、有益なデフォルトなどを提供するかどうかを考慮します。このプロセスは主観的で、正確な標準はありません。モジュールが受け入れられる可能性を最大限に高めるには、「:ref:`モジュール開発のヒント `」に従ってください。" #: ../../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 `." msgstr ":ref:`モジュール開発のヒント `" #: ../../rst/dev_guide/developing_modules_checklist.rst:45 msgid ":ref:`Amazon development checklist `." msgstr ":ref:`Amazon 開発チェックリスト `" #: ../../rst/dev_guide/developing_modules_checklist.rst:46 msgid ":ref:`Windows development checklist `." msgstr ":ref:`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 ` apply.) In addition to following this format, you should review our :ref:`submission checklist `, :ref:`programming tips `, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility `, as well as information about :ref:`testing ` before you open a pull request." msgstr "モジュールをほとんどの Ansible コレクションに貢献する場合は、Python でモジュールを作成して、その標準形式に従う必要があります。(Windows モジュールを作成したことがない場合。この場合は、:ref:`Windows ガイドライン ` が適用されます)。この形式に従うことに加え、プル要求を作成する前に、:ref:`提出のチェックリスト `、:ref:`プログラムのヒント `、:ref:`Python 2 および Python 3 互換性の維持のストラテジー ` と、:ref:`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`` が機能します)。``# -*- coding: utf-8 -*-`` ファイルが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 `_ 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 `_ があるはずです。ライセンス宣言は、完全な GPL プレフィックスではなく、1 行のみにする必要があります。" #: ../../rst/dev_guide/developing_modules_documenting.rst:46 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 行目の著作権行を追加する場合は、古い行の上に新しい行を追加します。" #: ../../rst/dev_guide/developing_modules_documenting.rst:62 msgid "ANSIBLE_METADATA block" msgstr "ansible_METADATA ブロック" #: ../../rst/dev_guide/developing_modules_documenting.rst:64 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:70 msgid "DOCUMENTATION block" msgstr "DOCUMENTATION ブロック" #: ../../rst/dev_guide/developing_modules_documenting.rst:72 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 ` before you include it in your Python file. You can start by copying our `example documentation string `_ into your module file and modifying it. If you run into syntax issues in your YAML, you can validate it on the `YAML Lint `_ website." msgstr "shebang、UTF-8 コーディング、著作権行、ライセンスセクションの後には、``DOCUMENTATION`` ブロックがあります。Ansible のオンラインモジュールドキュメントは、各モジュールのソースコード内の ``DOCUMENTATION`` ブロックから生成されます。``DOCUMENTATION`` ブロックは有効な YAML でなければなりません。Python ファイルに含める前に、``DOCUMENTATION`` の文字列を :ref:`YAML 構文の強調表示を使用したエディター ` に書き始めた方が簡単だと思うかもしれません。私たちの `例のドキュメントの文字列 `_ をあなたのモジュールファイルにコピーして、それを修正することから始めることができます。もし YAML の構文に問題がある場合は、`YAML Lint `_ の Web サイトで検証することができます。" #: ../../rst/dev_guide/developing_modules_documenting.rst:80 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:75 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:76 msgid "Verify that arguments in doc and module spec dict are identical." msgstr "ドキュメントの引数と、モジュール仕様のディクショナリーが同じであることを確認します。" #: ../../rst/dev_guide/developing_modules_documenting.rst:77 msgid "For password / secret arguments ``no_log=True`` should be set." msgstr "パスワード/シークレット引数 ``no_log=True`` を設定する必要があります。" #: ../../rst/dev_guide/developing_modules_documenting.rst:78 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:79 #: ../../rst/dev_guide/developing_modules_documenting.rst:147 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:80 msgid "If your module allows ``check_mode``, reflect this fact in the documentation." msgstr "モジュールで ``check_mode`` が許可されている場合は、これをドキュメントに反映させます。" #: ../../rst/dev_guide/developing_modules_documenting.rst:82 msgid "To create clear, concise, consistent, and useful documentation, follow the :ref:`style guide `." msgstr "明確かつ簡潔で一貫性があり、便利なドキュメントは :ref:`スタイルガイド ` に従います。" #: ../../rst/dev_guide/developing_modules_documenting.rst:84 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:86 msgid "As long as your module file is :ref:`available locally `, 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:`ローカルで利用可能 ` な場合に限り、``ansible-doc -t module my_module_name`` を使用して、コマンドラインでモジュールのドキュメントを表示します。構文解析エラーは明確になります。コマンドに ``-vvv`` を追加すると、詳細を表示できます。" #: ../../rst/dev_guide/developing_modules_documenting.rst:87 msgid "You should also :ref:`test the HTML output ` of your module documentation." msgstr "モジュールのドキュメントにおける :ref:`HTML 出力のテスト ` も必要です。" #: ../../rst/dev_guide/developing_modules_documenting.rst:90 msgid "Documentation fields" msgstr "ドキュメントフィールド" #: ../../rst/dev_guide/developing_modules_documenting.rst:92 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:96 msgid "The name of the module." msgstr "モジュールの名前。" #: ../../rst/dev_guide/developing_modules_documenting.rst:97 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:101 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:102 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:104 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 "説明" #: ../../rst/dev_guide/developing_modules_documenting.rst:108 msgid "A detailed description (generally two or more sentences)." msgstr "詳細な説明 (通常は 2 文以上)。" #: ../../rst/dev_guide/developing_modules_documenting.rst:109 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:110 msgid "Shouldn't mention the module name." msgstr "モジュール名について言及すべきではありません。" #: ../../rst/dev_guide/developing_modules_documenting.rst:111 msgid "Make use of multiple entries rather than using one long paragraph." msgstr "1 つの長い段落にせず、複数の文章に分けます。" #: ../../rst/dev_guide/developing_modules_documenting.rst:112 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:116 msgid "The version of Ansible when the module was added." msgstr "モジュールが追加された Ansible のバージョン。" #: ../../rst/dev_guide/developing_modules_documenting.rst:117 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:118 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 "作成者" #: ../../rst/dev_guide/developing_modules_documenting.rst:122 msgid "Name of the module author in the form ``First Last (@GitHubID)``." msgstr "``First Last (@GitHubID)`` 形式のモジュール作成者の名前。" #: ../../rst/dev_guide/developing_modules_documenting.rst:123 msgid "Use a multi-line list if there is more than one author." msgstr "作成者が複数になる場合は、複数行のリストを使用します。" #: ../../rst/dev_guide/developing_modules_documenting.rst:124 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 "非推奨" #: ../../rst/dev_guide/developing_modules_documenting.rst:128 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:132 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:133 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:134 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:138 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:139 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:140 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:144 msgid "Detailed explanation of what this option does. It should be written in full sentences." msgstr "* このオプションの機能の詳細な説明。これは、完全な文章で記述する必要があります。" #: ../../rst/dev_guide/developing_modules_documenting.rst:145 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:146 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:148 msgid "Mutually exclusive options must be documented as the final sentence on each of the options." msgstr "相互に排他的なオプションは、各オプションの最後の文で文書化する必要があります。" #: ../../rst/dev_guide/developing_modules_documenting.rst:152 msgid "Only needed if ``true``." msgstr "``true`` の場合にのみ必要です。" #: ../../rst/dev_guide/developing_modules_documenting.rst:153 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:157 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:158 msgid "Ensure that the default value in the docs matches the default value in the code." msgstr "ドキュメントのデフォルト値が、コードのデフォルト値と一致していることを確認してください。" #: ../../rst/dev_guide/developing_modules_documenting.rst:159 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:160 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:165 msgid "List of option values." msgstr "* オプション値のリスト。" #: ../../rst/dev_guide/developing_modules_documenting.rst:166 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 "タイプ" #: ../../rst/dev_guide/developing_modules_documenting.rst:170 msgid "Specifies the data type that option accepts, must match the ``argspec``." msgstr "オプションで使用できるデータ型を指定します。``argspec`` と一致させる必要があります。" #: ../../rst/dev_guide/developing_modules_documenting.rst:171 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:172 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:176 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:179 msgid "List of optional name aliases." msgstr "オプションの名前エイリアスのリスト。" #: ../../rst/dev_guide/developing_modules_documenting.rst:180 msgid "Generally not needed." msgstr "* 一般的には必要ありません。" #: ../../rst/dev_guide/developing_modules_documenting.rst:184 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:185 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:186 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:190 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:191 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:195 msgid "List of requirements (if applicable)." msgstr "要件のリスト (該当する場合)。" #: ../../rst/dev_guide/developing_modules_documenting.rst:196 msgid "Include minimum versions." msgstr "最小バージョンを指定します。" #: ../../rst/dev_guide/developing_modules_documenting.rst msgid "seealso" msgstr "seealso" #: ../../rst/dev_guide/developing_modules_documenting.rst:200 msgid "A list of references to other modules, documentation or Internet resources" msgstr "その他のモジュール、ドキュメント、またはインターネットリソースへの参照の一覧。" #: ../../rst/dev_guide/developing_modules_documenting.rst:201 msgid "In Ansible 2.10 and later, references to modules must use the FQCN or ``ansible.builtin`` for modules in ``ansible-base``." msgstr "Ansible 2.10 以降では、モジュールへの参照が ``ansible-base`` のモジュールに FQCN または ``ansible.builtin`` を使用する必要があります。" #: ../../rst/dev_guide/developing_modules_documenting.rst:202 msgid "A reference can be one of the following formats:" msgstr "参照には、以下の形式のいずれかを使用できます。" #: ../../rst/dev_guide/developing_modules_documenting.rst msgid "notes" msgstr "備考" #: ../../rst/dev_guide/developing_modules_documenting.rst:227 msgid "Details of any important information that doesn't fit in one of the above sections." msgstr "上記のセクションのいずれかに該当しない重要な情報の詳細。" #: ../../rst/dev_guide/developing_modules_documenting.rst:228 msgid "For example, whether ``check_mode`` is or is not supported." msgstr "たとえば、``check_mode`` がサポートされるかどうかなどです。" #: ../../rst/dev_guide/developing_modules_documenting.rst:232 msgid "Linking and other format macros within module documentation" msgstr "モジュールドキュメント内のリンクおよびその他の形式マクロ" #: ../../rst/dev_guide/developing_modules_documenting.rst:234 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:236 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()`` を使用しないでください。" #: ../../rst/dev_guide/developing_modules_documenting.rst:237 msgid "``U()`` for URLs. For example: ``See U(https://www.ansible.com/products/tower) for an overview.``" msgstr "URL の場合は ``U()``。たとえば、``See U(https://www.ansible.com/products/tower) for an overview.`` となります。" #: ../../rst/dev_guide/developing_modules_documenting.rst:238 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:239 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:241 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:244 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:246 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:247 msgid "``B()`` currently has no standardized usage. It is displayed in boldface in the documentation." msgstr "``B()`` は、現在、標準化された使用はありません。このドキュメントには太字が表示されます。" #: ../../rst/dev_guide/developing_modules_documenting.rst:248 msgid "``HORIZONTALLINE`` is used sparingly as a separator in long descriptions. It becomes a horizontal rule (the ``
`` html tag) in the documentation." msgstr "``HORIZONTALLINE`` は、長い説明では、区切り文字として慎重に使用されており、ドキュメント内の水平ルール (``
`` html タグ) になります。" #: ../../rst/dev_guide/developing_modules_documenting.rst:252 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 `_ to convert ``R()`` and ``M()`` to the correct links." msgstr "コレクション内のモジュールとドキュメント間のリンクについては、上記のオプションのいずれかを使用することができます。コレクション外のリンクについては、利用可能な場合は ``R()`` を使用します。利用できない場合は、(相対リンクではなく) 完全な URL で ``U()`` または ``L()`` を使用します。モジュールの場合は、例のように、FQCN または ``ansible.builtin`` で ``M()`` を使用します。独自のドキュメントサイトを作成する場合は、`intersphinx extension `_ を使用して ``R()`` および ``M()`` を正しいリンクに変換する必要があります。" #: ../../rst/dev_guide/developing_modules_documenting.rst:256 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:258 msgid "``Refer to the R(community.kubernetes collection, plugins_in_community.kubernetes) for information on managing kubernetes clusters.``" msgstr "``Refer to the R(community.kubernetes collection, plugins_in_community.kubernetes) for information on managing kubernetes clusters.``" #: ../../rst/dev_guide/developing_modules_documenting.rst:259 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:264 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:269 msgid "Documentation fragments" msgstr "ドキュメントフラグメント" #: ../../rst/dev_guide/developing_modules_documenting.rst:271 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/ `_ 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, ``community.kubernetes.k8s_auth_options``)." msgstr "複数の関連モジュールを記述している場合は、認証の詳細やファイルモードの設定、``notes:`` や``seealso:`` のエントリーなど、共通のドキュメントを共有していることがあります。そのような情報を各モジュールの ``DOCUMENTATION`` ブロックに複製するのではなく、doc_fragment プラグインとして一度保存し、各モジュールのドキュメントで使用することができます。Ansibl eでは、共有ドキュメントフラグメントは、`lib/ansible/plugins/doc_fragments/ `_ の ``ModuleDocFragment`` クラス、またはコレクションの同等のディレクトリーに含まれています。ドキュメントフラグメントを含めるには、モジュールのドキュメントに ``extends_documentation_fragment: FRAGMENT_NAME`` を追加します。FRAGMENT_NAME には、完全修飾されたコレクション名を使用します (例： ``community.kubernetes.k8s_auth_options``)。" #: ../../rst/dev_guide/developing_modules_documenting.rst:273 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:275 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 "デフォルトでは、doc フラグメントの ``DOCUMENTATION`` プロパティーがモジュールのドキュメントに挿入されます。doc フラグメントの特定の部分のみをインポートするため、または必要に応じて組み合わせて一致させるために、doc フラグメントに追加のプロパティーを定義することができます。プロパティーが doc フラグメントとモジュールの両方で定義されている場合、モジュール値は doc フラグメントを上書きします。" #: ../../rst/dev_guide/developing_modules_documenting.rst:277 msgid "Here is an example doc fragment named ``example_fragment.py``:" msgstr "以下は、``example_fragment.py`` という名前の doc フラグメントの例です。" #: ../../rst/dev_guide/developing_modules_documenting.rst:295 msgid "To insert the contents of ``OTHER`` in a module:" msgstr "``OTHER`` の内容をモジュールに挿入するには、以下を行います。" #: ../../rst/dev_guide/developing_modules_documenting.rst:301 msgid "Or use both :" msgstr "または、以下の両方を使用してください。" #: ../../rst/dev_guide/developing_modules_documenting.rst:314 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`` ディレクトリーを使用することで、ユーザーが提供する doc_fragments を設定できます。" #: ../../rst/dev_guide/developing_modules_documenting.rst:316 msgid "For example, all AWS modules should include:" msgstr "たとえば、すべての AWS モジュールには以下を含める必要があります。" #: ../../rst/dev_guide/developing_modules_documenting.rst:324 msgid ":ref:`docfragments_collections` describes how to incorporate documentation fragments in a collection." msgstr "「:ref:`docfragments_collections`」では、コレクションにドキュメントのフラグメントを組み込む方法を説明します。" #: ../../rst/dev_guide/developing_modules_documenting.rst:329 msgid "EXAMPLES block" msgstr "EXAMPLES ブロック" #: ../../rst/dev_guide/developing_modules_documenting.rst:331 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:333 msgid "Per playbook best practices, each example should include a ``name:`` line::" msgstr "Playbook のベストプラクティスに基づき、各例には ``name:`` 行が必要です。" #: ../../rst/dev_guide/developing_modules_documenting.rst:342 msgid "The ``name:`` line should be capitalized and not include a trailing dot." msgstr "``name:`` 行は大文字にし、末尾のドットは含めないでください。" #: ../../rst/dev_guide/developing_modules_documenting.rst:344 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-base``, use the ``ansible.builtin.`` identifier, for example ``ansible.builtin.debug``." msgstr "上記の例のように、モジュール名の一部として完全修飾コレクション名 (FQCN) を使用します。``ansible-base`` のモジュールの場合は、``ansible.builtin.`` 識別子 (たとえば ``ansible.builtin.debug``) を使用します。" #: ../../rst/dev_guide/developing_modules_documenting.rst:346 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:348 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:353 msgid "RETURN block" msgstr "RETURN ブロック" #: ../../rst/dev_guide/developing_modules_documenting.rst:355 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:357 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:361 msgid "Name of the returned field." msgstr "返されるフィールドの名前。" #: ../../rst/dev_guide/developing_modules_documenting.rst:364 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:366 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:368 msgid "Data type." msgstr "データ型。" #: ../../rst/dev_guide/developing_modules_documenting.rst:370 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 "サンプル" #: ../../rst/dev_guide/developing_modules_documenting.rst:372 msgid "One or more examples." msgstr "1 つ以上の例。" #: ../../rst/dev_guide/developing_modules_documenting.rst:374 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:377 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:379 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:427 msgid "Python imports" msgstr "Python のインポート" #: ../../rst/dev_guide/developing_modules_documenting.rst:429 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:435 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:440 #: ../../rst/dev_guide/testing_documentation.rst:7 msgid "Testing module documentation" msgstr "モジュールドキュメンテーションのテスト" #: ../../rst/dev_guide/developing_modules_documenting.rst:442 msgid "To test Ansible documentation locally please :ref:`follow instruction`." msgstr "Ansible ドキュメントをローカルでテストするには、「:ref:`指示に従う`」を参照してください。" #: ../../rst/dev_guide/developing_modules_general.rst:6 msgid "Developing Ansible modules" msgstr "Ansible モジュールの開発" #: ../../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:18 msgid "Preparing an environment for developing Ansible modules" msgstr "Ansible モジュール開発用の環境の準備" #: ../../rst/dev_guide/developing_modules_general.rst:21 msgid "Installing prerequisites via apt (Ubuntu)" msgstr "apt (Ubuntu) を使用した前提条件のインストール" #: ../../rst/dev_guide/developing_modules_general.rst:23 msgid "Due to dependencies (for example ansible -> paramiko -> pynacl -> libffi):" msgstr "依存関係のため (例: ansible -> paramiko -> pynacl -> libffi)。" #: ../../rst/dev_guide/developing_modules_general.rst:31 msgid "Creating a development environment (platform-agnostic steps)" msgstr "開発環境の作成 (プラットフォームに依存しない手順)" #: ../../rst/dev_guide/developing_modules_general.rst:33 msgid "Clone the Ansible repository: ``$ git clone https://github.com/ansible/ansible.git``" msgstr "Ansible リポジトリーのクローンを作成します (``$ git clone https://github.com/ansible/ansible.git``)。" #: ../../rst/dev_guide/developing_modules_general.rst:35 msgid "Change directory into the repository root dir: ``$ cd ansible``" msgstr "ディレクトリーをリポジトリーの root ディレクトリーに変更します (``$ cd ansible``)。" #: ../../rst/dev_guide/developing_modules_general.rst:36 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`` をインストールする必要があります。" #: ../../rst/dev_guide/developing_modules_general.rst:39 msgid "Activate the virtual environment: ``$ . venv/bin/activate``" msgstr "仮想環境をアクティベートします (``$ . venv/bin/activate``)。" #: ../../rst/dev_guide/developing_modules_general.rst:40 msgid "Install development requirements: ``$ pip install -r requirements.txt``" msgstr "開発要件をインストールします (``$ pip install -r requirements.txt``)。" #: ../../rst/dev_guide/developing_modules_general.rst:42 msgid "Run the environment setup script for each new dev shell process: ``$ . hacking/env-setup``" msgstr "新規 dev シェルプロセスごとに環境設定スクリプトを実行します (``$ . hacking/env-setup``)。" #: ../../rst/dev_guide/developing_modules_general.rst:45 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`` を実行できるはずです。" #: ../../rst/dev_guide/developing_modules_general.rst:52 msgid "Creating an info or a facts module" msgstr "情報またはファクトモジュールの作成" #: ../../rst/dev_guide/developing_modules_general.rst:54 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:57 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:59 msgid "If a module is named ``_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 "モジュールの名前が ``_facts`` の場合、主な目的は ``ansible_facts`` を返しているからです。これは、``_facts`` で行わないモジュールに名前を付けないでください。ネットワークインターフェース、その設定など、オペレーティングシステムと、インストールされているプログラムなど、ホストマシンに固有の情報には ``ansible_facts`` のみを使用してください。" #: ../../rst/dev_guide/developing_modules_general.rst:62 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:65 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:67 msgid "They MUST be named ``_info`` or ``_facts``, where is singular." msgstr "名前は ``_info`` または ``_facts`` です。 は単数になります。" #: ../../rst/dev_guide/developing_modules_general.rst:68 msgid "Info ``*_info`` modules MUST return in the form of the :ref:`result dictionary` so other modules can access them." msgstr "info の ``*_info`` モジュールは、他のモジュールがアクセスできるように :ref:`結果ディレクトリー` の形式で返す必要があります。" #: ../../rst/dev_guide/developing_modules_general.rst:69 msgid "Fact ``*_facts`` modules MUST return in the ``ansible_facts`` field of the :ref:`result dictionary` so other modules can access them." msgstr "fact の ``*_facts`` モジュールは、他のモジュールがそれらにアクセスできるように :ref:`結果ディレクトリー` の ``ansible_facts`` フィールドに返す必要があります。" #: ../../rst/dev_guide/developing_modules_general.rst:70 msgid "They MUST support :ref:`check_mode `." msgstr ":ref:`check_mode ` をサポートする必要があります。" #: ../../rst/dev_guide/developing_modules_general.rst:71 msgid "They MUST NOT make any changes to the system." msgstr "システムに変更を加えないでください。" #: ../../rst/dev_guide/developing_modules_general.rst:72 msgid "They MUST document the :ref:`return fields` and :ref:`examples`." msgstr ":ref:`return fields` および :ref:`examples` を文書化する必要があります。" #: ../../rst/dev_guide/developing_modules_general.rst:74 msgid "To create an info module:" msgstr "info モジュールを作成するには、次を実行します。" #: ../../rst/dev_guide/developing_modules_general.rst:76 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/`` を実行します。" #: ../../rst/dev_guide/developing_modules_general.rst:77 msgid "Create your new module file: ``$ touch my_test_info.py``." msgstr "新しいモジュールファイルを作成します (``$ touch my_test_info.py``)。" #: ../../rst/dev_guide/developing_modules_general.rst:78 msgid "Paste the content below into your new info module file. It includes the :ref:`required Ansible format and documentation `, a simple :ref:`argument spec for declaring the module options `, and some example code." msgstr "以下の内容を新しい情報モジュールファイルに貼り付けます。これには、:ref:`必須の Ansible 形式およびドキュメント `、:ref:`モジュールオプションを宣言する単純な引数仕様 `、およびサンプルコードが含まれます。" #: ../../rst/dev_guide/developing_modules_general.rst:79 msgid "Modify and extend the code to do what you want your new info module to do. See the :ref:`programming tips ` and :ref:`Python 3 compatibility ` pages for pointers on writing clean and concise module code." msgstr "新しい情報モジュールが実行することを行えるようにコードを変更し、拡張します。余計なものが入っていないモジュールコードや、簡潔なモジュールコードの作成に関するヒントは、「:ref:`プログラミングのヒント `」ページおよび「:ref:`Python 3 互換性 `」ページを参照してください。" #: ../../rst/dev_guide/developing_modules_general.rst:84 msgid "Use the same process to create a facts module." msgstr "同じプロセスを使用してファクトモジュールを作成します。" #: ../../rst/dev_guide/developing_modules_general.rst:90 msgid "Creating a module" msgstr "モジュールの作成" #: ../../rst/dev_guide/developing_modules_general.rst:92 msgid "To create a module:" msgstr "モジュールを作成するには、以下を行います。" #: ../../rst/dev_guide/developing_modules_general.rst:94 msgid "Navigate to the correct directory for your new module: ``$ cd lib/ansible/modules/``. If you are developing a module in a :ref:`collection `, ``$ cd plugins/modules/`` inside your collection development tree." msgstr "新しいモジュールの正しいディレクトリーに移動します (``$ cd lib/ansible/modules/``)。:ref:`コレクション ` でモジュールを開発する場合は、コレクション開発ツリー内で ``$ cd plugins/modules/`` を実行します。" #: ../../rst/dev_guide/developing_modules_general.rst:95 msgid "Create your new module file: ``$ touch my_test.py``." msgstr "新しいモジュールファイルを作成します (``$ touch my_test.py``)。" #: ../../rst/dev_guide/developing_modules_general.rst:96 msgid "Paste the content below into your new module file. It includes the :ref:`required Ansible format and documentation `, a simple :ref:`argument spec for declaring the module options `, and some example code." msgstr "以下の内容を新しいモジュールファイルに貼り付けます。これには、:ref:`必須の Ansible 形式およびドキュメント `、:ref:`モジュールオプションを宣言する単純な引数仕様 `、およびサンプルコードが含まれます。" #: ../../rst/dev_guide/developing_modules_general.rst:97 msgid "Modify and extend the code to do what you want your new module to do. See the :ref:`programming tips ` and :ref:`Python 3 compatibility ` pages for pointers on writing clean and concise module code." msgstr "新しいモジュールが実行することを行えるようにコードを変更し、拡張します。余計なものが入っていないモジュールコードや、簡潔なモジュールコードの作成に関するヒントは、「:ref:`プログラミングのヒント `」ページおよび」:ref:`Python 3 互換性 `」ページを参照してください。" #: ../../rst/dev_guide/developing_modules_general.rst:103 msgid "Verifying your module code" msgstr "モジュールコードの確認" #: ../../rst/dev_guide/developing_modules_general.rst:105 msgid "After you modify the sample code above to do what you want, you can try out your module. Our :ref:`debugging tips ` will help if you run into bugs as you verify your module code." msgstr "上記のサンプルコードを修正した後に、モジュールを試すことができます。:ref:`debugging tips ` は、モジュールコードを検証する際にバグが発生した場合に役立ちます。" #: ../../rst/dev_guide/developing_modules_general.rst:110 msgid "Verifying your module code locally" msgstr "モジュールコードのローカルでの確認" #: ../../rst/dev_guide/developing_modules_general.rst:112 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:114 msgid "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 "引数ファイルを作成します。これは、モジュールを実行できるようにパラメーターをモジュールに渡す基本的な JSON 構成ファイルです。引数ファイル ``/tmp/args.json`` に名前を付け、以下の内容を追加します。" #: ../../rst/dev_guide/developing_modules_general.rst:125 msgid "If you are using a virtual environment (which is highly recommended for development) activate it: ``$ . venv/bin/activate``" msgstr "(開発に非常に推奨されている) 仮想環境を使用している場合は、アクティベートします (``$ . venv/bin/activate``)。" #: ../../rst/dev_guide/developing_modules_general.rst:127 msgid "Set up the environment for development: ``$ . hacking/env-setup``" msgstr "開発用の環境を設定します (``$ . hacking/env-setup``)。" #: ../../rst/dev_guide/developing_modules_general.rst:128 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``)。" #: ../../rst/dev_guide/developing_modules_general.rst:131 msgid "This should return output like this:" msgstr "これにより、以下のような出力が返されます。" #: ../../rst/dev_guide/developing_modules_general.rst:139 msgid "Verifying your module code in a playbook" msgstr "Playbook でのモジュールコードの確認" #: ../../rst/dev_guide/developing_modules_general.rst:141 msgid "The next step in verifying your new module is to consume it with an Ansible playbook." msgstr "新規モジュールを検証する次のステップは、Ansible Playbook で使用します。" #: ../../rst/dev_guide/developing_modules_general.rst:143 msgid "Create a playbook in any directory: ``$ touch testmod.yml``" msgstr "任意のディレクトリーに Playbook を作成します (``$ touch testmod.yml``)。" #: ../../rst/dev_guide/developing_modules_general.rst:144 #: ../../rst/dev_guide/developing_modules_general_windows.rst:521 msgid "Add the following to the new playbook file::" msgstr "以下を新しい Playbook ファイルに追加します。" #: ../../rst/dev_guide/developing_modules_general.rst:158 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:161 msgid "Testing your newly-created module" msgstr "新たに作成したモジュールのテスト" #: ../../rst/dev_guide/developing_modules_general.rst:163 msgid "The following two examples will get you started with testing your module code. Please review our :ref:`testing ` section for more detailed information, including instructions for :ref:`testing module documentation `, adding :ref:`integration tests `, and more." msgstr "以下の 2 つの例は、モジュールコードのテストを開始します。:ref:`モジュールのテストのドキュメント ` の手順、:ref:`統合テスト ` の追加などの詳細な情報は、:ref:`testing ` のセクションを参照してください。" #: ../../rst/dev_guide/developing_modules_general.rst:167 #: ../../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 `_." msgstr "テストを Ansible CI インフラストラクチャーで実行できない場合でも、新しいモジュールとプラグインには統合テストが必要です。この場合、テストは `aliases file `_ の ``unsupported`` エイリアスでマーク付けする必要があります。" #: ../../rst/dev_guide/developing_modules_general.rst:171 msgid "Performing sanity tests" msgstr "サニティーテストの実行" #: ../../rst/dev_guide/developing_modules_general.rst:173 msgid "You can run through Ansible's sanity checks in a container:" msgstr "Ansible の健全性チェックをコンテナーで実行できます。" #: ../../rst/dev_guide/developing_modules_general.rst:175 msgid "``$ ansible-test sanity -v --docker --python 2.7 MODULE_NAME``" msgstr "``$ ansible-test sanity -v --docker --python 2.7 MODULE_NAME``" #: ../../rst/dev_guide/developing_modules_general.rst:178 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:181 msgid "Adding unit tests" msgstr "ユニットテストの追加" #: ../../rst/dev_guide/developing_modules_general.rst:183 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 を使用しています。" #: ../../rst/dev_guide/developing_modules_general.rst:185 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``)。" #: ../../rst/dev_guide/developing_modules_general.rst:186 msgid "Run ``. hacking/env-setup``" msgstr "``. hacking/env-setup`` を実行します。" #: ../../rst/dev_guide/developing_modules_general.rst:187 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 環境を使用している場合は、これらのテストが自動的に実行されます。" #: ../../rst/dev_guide/developing_modules_general.rst:189 msgid "Ansible uses pytest for unit testing." msgstr "Ansible はユニットテストに pytest を使用します。" #: ../../rst/dev_guide/developing_modules_general.rst:191 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 を実行するには、以下のコマンドを実行します。テストモジュールの正しいパスを提供していることを確認してください。" #: ../../rst/dev_guide/developing_modules_general.rst:193 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``" #: ../../rst/dev_guide/developing_modules_general.rst:197 msgid "Contributing back to Ansible" msgstr "Ansible への貢献" #: ../../rst/dev_guide/developing_modules_general.rst:199 msgid "If you would like to contribute to ``ansible-base`` by adding a new feature or fixing a bug, `create a fork `_ of the ansible/ansible repository and develop against a new feature branch using the ``devel`` branch as a starting point. When you 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-base`` に貢献する場合は、ansible/ansible リポジトリーの ansible/ansible リポジトリーの `フォークを作成 `_ し、開始点として ``devel`` ブランチを使用して新機能ブランチに対して開発します。適切な作業コードも変更がある場合は、機能ブランチをソースとして、およびAnsible devel ブランチをターゲットとして選択し、Ansible リポジトリーにプルリクエストを送信します。" #: ../../rst/dev_guide/developing_modules_general.rst:201 msgid "If you want to contribute a module to an :ref:`Ansible collection `, review our :ref:`submission checklist `, :ref:`programming tips `, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility `, as well as information about :ref:`testing ` before you open a pull request." msgstr "モジュールを :ref:`Ansible コレクション ` に提供したい場合は、:ref:`提出のチェックアウト `、:ref:`プログラムのヒント `、および :ref:`Python 2 および Python 3 の互換性を維持するストラテジー ` を確認してください。プルリクエストを作成する前に、:ref:`テスト ` に関する情報も併せて参照してください。" #: ../../rst/dev_guide/developing_modules_general.rst:203 msgid "The :ref:`Community Guide ` covers how to open a pull request and what happens next." msgstr ":ref:`コミュニティーガイド ` では、プルリクエストを開く方法と、次に実行することを説明します。" #: ../../rst/dev_guide/developing_modules_general.rst:207 msgid "Communication and development support" msgstr "通信および開発のサポート" #: ../../rst/dev_guide/developing_modules_general.rst:209 msgid "Join the IRC channel ``#ansible-devel`` on freenode for discussions surrounding Ansible development." msgstr "Ansible 開発に取り組むため、freenode の IRC チャンネル ``#ansible-devel`` に参加します。" #: ../../rst/dev_guide/developing_modules_general.rst:212 #: ../../rst/dev_guide/developing_modules_general_windows.rst:695 msgid "For questions and discussions pertaining to using the Ansible product, use the ``#ansible`` channel." msgstr "Ansible 製品の使用に関する質問および貢献については、``#ansible`` チャンネルを使用します。" #: ../../rst/dev_guide/developing_modules_general.rst:215 msgid "For more specific IRC channels look at :ref:`Community Guide, Communicating `." msgstr "より具体的な IRC チャンネルは、「:ref:`Community Guide, Communicating `」を参照してください。" #: ../../rst/dev_guide/developing_modules_general.rst:218 msgid "Credit" msgstr "謝辞" #: ../../rst/dev_guide/developing_modules_general.rst:220 msgid "Thank you to Thomas Stringer (`@trstringer `_) for contributing source material for this topic." msgstr "このトピックの元となる資料を提供していただいた Thomas Stringer (`@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 `." msgstr "Cisco ACI の詳細は、「:ref:`Cisco ACI ユーザーガイド `」を参照してください。" #: ../../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 `_ 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 `_ にはすでに多数の 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 ` module" msgstr "ACI オブジェクトモデルを学習し、「:ref:`aci_rest `」モジュールを使用して低レベルの 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 msgid "`ACI Fundamentals: ACI Policy Model `_" msgstr "`ACI Fundamentals: ACI Policy Model `_" #: ../../rst/dev_guide/developing_modules_general_aci.rst:31 msgid "A good introduction to the ACI object model." msgstr "ACI オブジェクトモデルの優れた概要。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:32 msgid "`APIC Management Information Model reference `_" msgstr "`APIC Management Information Model reference `_" #: ../../rst/dev_guide/developing_modules_general_aci.rst:33 msgid "Complete reference of the APIC object model." msgstr "APIC オブジェクトモデルの完全なリファレンス。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:34 msgid "`APIC REST API Configuration Guide `_" msgstr "`APIC REST API Configuration Guide `_" #: ../../rst/dev_guide/developing_modules_general_aci.rst:35 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:38 msgid "So let's look at how a typical ACI module is built up." msgstr "それでは、典型的な ACI モジュールがどのように構築されるかを見てみましょう。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:44 msgid "ACI module structure" msgstr "ACI モジュール構造" #: ../../rst/dev_guide/developing_modules_general_aci.rst:47 msgid "Importing objects from Python libraries" msgstr "Python ライブラリーからのオブジェクトのインポート" #: ../../rst/dev_guide/developing_modules_general_aci.rst:48 msgid "The following imports are standard across ACI modules:" msgstr "以下のインポートは、ACI モジュール全体で標準のものです。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:57 msgid "Defining the argument spec" msgstr "引数仕様の定義" #: ../../rst/dev_guide/developing_modules_general_aci.rst:58 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:60 msgid "the object_id (usually the name)" msgstr "object_id (通常は名前)" #: ../../rst/dev_guide/developing_modules_general_aci.rst:61 msgid "the configurable properties of the object" msgstr "オブジェクトの設定可能なプロパティー" #: ../../rst/dev_guide/developing_modules_general_aci.rst:62 msgid "the parent object IDs (all parents up to the root)" msgstr "親オブジェクト ID (ルートまでのすべての親)" #: ../../rst/dev_guide/developing_modules_general_aci.rst:63 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:64 msgid "the state" msgstr "状態" #: ../../rst/dev_guide/developing_modules_general_aci.rst:66 msgid "``state: absent`` to ensure object does not exist" msgstr "``state: absent``: オブジェクトが存在しないことを確認する" #: ../../rst/dev_guide/developing_modules_general_aci.rst:67 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:68 msgid "``state: query`` to retrieve information about objects in the class" msgstr "``state: query``: クラスのオブジェクトに関する情報を取得する" #: ../../rst/dev_guide/developing_modules_general_aci.rst:86 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:89 msgid "Using the AnsibleModule object" msgstr "AnsibleModule オブジェクトの使用" #: ../../rst/dev_guide/developing_modules_general_aci.rst:90 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:105 msgid "Mapping variable definition" msgstr "マッピング変数定義" #: ../../rst/dev_guide/developing_modules_general_aci.rst:106 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:122 msgid "Using the ACIModule object" msgstr "ACIModule オブジェクトの使用" #: ../../rst/dev_guide/developing_modules_general_aci.rst:123 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:129 msgid "The ACIModule has six main methods that are used by the modules:" msgstr "ACIModule には、モジュールによって使用される 6 つの主なメソッドがあります。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:131 msgid "construct_url" msgstr "construct_url" #: ../../rst/dev_guide/developing_modules_general_aci.rst:132 msgid "get_existing" msgstr "get_existing" #: ../../rst/dev_guide/developing_modules_general_aci.rst:133 msgid "payload" msgstr "payload" #: ../../rst/dev_guide/developing_modules_general_aci.rst:134 msgid "get_diff" msgstr "get_diff" #: ../../rst/dev_guide/developing_modules_general_aci.rst:135 msgid "post_config" msgstr "post_config" #: ../../rst/dev_guide/developing_modules_general_aci.rst:136 msgid "delete_config" msgstr "delete_config" #: ../../rst/dev_guide/developing_modules_general_aci.rst:138 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:141 msgid "Constructing URLs" msgstr "URL の構築" #: ../../rst/dev_guide/developing_modules_general_aci.rst:142 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:144 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:145 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:147 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 パラメーターで構成されている場合は、特定のオブジェクトのデータが返されます。ID パラメーターの一部が渡されると、モジュールは URL およびフィルター文字列を適切にビルドするために渡された ID を使用します。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:149 msgid "The ``construct_url()`` method takes 2 required arguments:" msgstr "``construct_url()`` メソッドは、必要な引数を 2 つ取ります。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:151 msgid "**self** - passed automatically with the class instance" msgstr "**self** - クラスインスタンスで自動的に渡されます。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:152 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:154 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:156 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:158 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:160 msgid "**module_object**: The particular object for this class, for example ``ACME``" msgstr "**module_object**: このクラスの特定のオブジェクト (例: ``ACME``)" #: ../../rst/dev_guide/developing_modules_general_aci.rst:162 #: ../../rst/dev_guide/developing_program_flow_modules.rst:597 #: ../../rst/dev_guide/developing_program_flow_modules.rst:636 #: ../../rst/dev_guide/developing_program_flow_modules.rst:650 #: ../../rst/dev_guide/developing_program_flow_modules.rst:750 #: ../../rst/dev_guide/developing_program_flow_modules.rst:767 #: ../../rst/dev_guide/developing_program_flow_modules.rst:781 #: ../../rst/dev_guide/developing_program_flow_modules.rst:808 #: ../../rst/dev_guide/developing_program_flow_modules.rst:825 #: ../../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:175 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:177 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:179 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:181 msgid "Example: Application Profile Class (AP)" msgstr "例: Application Profile Class (AP)" #: ../../rst/dev_guide/developing_modules_general_aci.rst:183 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:185 msgid "Example: End Point Group (EPG)" msgstr "例: エンドポイントグループ (EPG)" #: ../../rst/dev_guide/developing_modules_general_aci.rst:187 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:189 msgid "Example: Binding a Contract to an EPG" msgstr "例: EPG への契約のバインド" #: ../../rst/dev_guide/developing_modules_general_aci.rst:191 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:193 msgid "This is a list, even if it is a list of one" msgstr "1 つのリストであっても、これはリストです" #: ../../rst/dev_guide/developing_modules_general_aci.rst:194 msgid "These are the unfriendly names used by the APIC" msgstr "これらは、APIC が使用する分かりにくい名前です。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:195 msgid "These are used to limit the returned child_classes when possible" msgstr "可能な場合は、返された child_classes を制限するために使用されます。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:196 msgid "Example: ``child_classes=['fvRsBDSubnetToProfile', 'fvRsNdPfxPol']``" msgstr "例: ``child_classes=['fvRsBDSubnetToProfile', 'fvRsNdPfxPol']``" #: ../../rst/dev_guide/developing_modules_general_aci.rst:198 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:201 msgid "Getting the existing configuration" msgstr "既存設定の取得" #: ../../rst/dev_guide/developing_modules_general_aci.rst:202 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:204 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:205 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:206 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:214 msgid "When state is present" msgstr "state が present の場合" #: ../../rst/dev_guide/developing_modules_general_aci.rst:215 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-to-1 の関係にある子があります。これらの場合、モジュールは子オブジェクトを管理するために使用できます。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:218 msgid "Building the ACI payload" msgstr "ACI ペイロードの構築" #: ../../rst/dev_guide/developing_modules_general_aci.rst:219 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:221 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:223 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:224 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:226 msgid "The keys should match the names used by the APIC." msgstr "キーは APIC で使用される名前と一致する必要があります。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:227 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:229 msgid "``child_configs`` is optional, and is a list of child config dictionaries." msgstr "``child_configs`` は任意であり、子設定のディクショナリーの一覧です。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:231 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:232 msgid "The configuration portion is built the same way as the object." msgstr "設定部分は、オブジェクトと同じ方法で構築されます。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:256 msgid "Performing the request" msgstr "要求の実行" #: ../../rst/dev_guide/developing_modules_general_aci.rst:257 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:260 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:265 msgid "Example code" msgstr "サンプルコード" #: ../../rst/dev_guide/developing_modules_general_aci.rst:295 msgid "When state is absent" msgstr "state が absent の場合" #: ../../rst/dev_guide/developing_modules_general_aci.rst:296 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:305 msgid "Exiting the module" msgstr "モジュールの終了" #: ../../rst/dev_guide/developing_modules_general_aci.rst:306 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:319 msgid "Testing ACI library functions" msgstr "ACI ライブラリー関数のテスト" #: ../../rst/dev_guide/developing_modules_general_aci.rst:320 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:379 msgid "This will result in:" msgstr "これにより、以下が生成されます。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:393 msgid "Testing for sanity checks" msgstr "健全性チェックのテスト" #: ../../rst/dev_guide/developing_modules_general_aci.rst:394 msgid "You can run from your fork something like:" msgstr "次のようなフォークから実行できます。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:402 #: ../../rst/dev_guide/testing.rst:33 msgid ":ref:`testing_sanity`" msgstr ":ref:`testing_sanity`" #: ../../rst/dev_guide/developing_modules_general_aci.rst:403 msgid "Information on how to build sanity tests." msgstr "健全性テストを構築する方法に関する情報" #: ../../rst/dev_guide/developing_modules_general_aci.rst:407 msgid "Testing ACI integration tests" msgstr "ACI 統合テストのテスト" #: ../../rst/dev_guide/developing_modules_general_aci.rst:408 #: ../../rst/dev_guide/developing_modules_general_aci.rst:438 msgid "You can run this:" msgstr "以下を実行できます。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:414 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:416 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:432 #: ../../rst/dev_guide/testing.rst:37 msgid ":ref:`testing_integration`" msgstr ":ref:`testing_integration`" #: ../../rst/dev_guide/developing_modules_general_aci.rst:433 msgid "Information on how to build integration tests." msgstr "インテグレーションテストの構築方法に関する情報。" #: ../../rst/dev_guide/developing_modules_general_aci.rst:437 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 `_ repository which have also been uploaded to `Vagrant Cloud `_. 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 `_ リポジトリーによって作成された Vagrant ボックスを使用します。これは、`Vagrant Cloud `_ にアップロードされました。これらの画像がどのように作成されるかについての詳細は、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/WindowsServer2008-x86 `_" msgstr "`jborean93/WindowsServer2008-x86 `_" #: ../../rst/dev_guide/developing_modules_general_windows.rst:88 msgid "`jborean93/WindowsServer2008-x64 `_" msgstr "`jborean93/WindowsServer2008-x64 `_" #: ../../rst/dev_guide/developing_modules_general_windows.rst:89 msgid "`jborean93/WindowsServer2008R2 `_" msgstr "`jborean93/WindowsServer2008R2 `_" #: ../../rst/dev_guide/developing_modules_general_windows.rst:90 msgid "`jborean93/WindowsServer2012 `_" msgstr "`jborean93/WindowsServer2012 `_" #: ../../rst/dev_guide/developing_modules_general_windows.rst:91 msgid "`jborean93/WindowsServer2012R2 `_" msgstr "`jborean93/WindowsServer2012R2 `_" #: ../../rst/dev_guide/developing_modules_general_windows.rst:92 msgid "`jborean93/WindowsServer2016 `_" msgstr "`jborean93/WindowsServer2016 `_" #: ../../rst/dev_guide/developing_modules_general_windows.rst:94 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:99 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 `_ 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 `_ の Vagrant を使用して、Ansible で使用するテストドメイン環境を作成できます。このリポジトリーには、Ansible と Vagrant で使用されている 3 つのファイルが含まれ、ドメイン環境で複数の Windows ホストを作成するのに使用できます。このファイルは、以下のようになります。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:106 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:107 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:108 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:110 msgid "By default, these files will create the following environment:" msgstr "デフォルトでは、これらのファイルは以下の環境を作成します。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:112 msgid "A single domain controller running on Windows Server 2016" msgstr "Windows Server 2016 で実行しているドメインコントローラー 1 つ" #: ../../rst/dev_guide/developing_modules_general_windows.rst:113 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:114 msgid "A domain with the DNS name ``domain.local``" msgstr "DNS 名 ``domain.local`` を持つドメイン" #: ../../rst/dev_guide/developing_modules_general_windows.rst:115 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:116 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:118 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:127 msgid "Provisioning the environment" msgstr "環境のプロビジョニング" #: ../../rst/dev_guide/developing_modules_general_windows.rst:129 msgid "To provision the environment as is, run the following:" msgstr "そのまま環境をプロビジョニングするには、次を実行します。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:137 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:141 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:148 msgid "``RDP``: 295xx" msgstr "``RDP``: 295xx" #: ../../rst/dev_guide/developing_modules_general_windows.rst:149 msgid "``SSH``: 296xx" msgstr "``SSH``: 296xx" #: ../../rst/dev_guide/developing_modules_general_windows.rst:150 msgid "``WinRM HTTP``: 297xx" msgstr "``WinRM HTTP``: 297xx" #: ../../rst/dev_guide/developing_modules_general_windows.rst:151 msgid "``WinRM HTTPS``: 298xx" msgstr "``WinRM HTTPS``: 298xx" #: ../../rst/dev_guide/developing_modules_general_windows.rst:152 msgid "``SMB``: 299xx" msgstr "``SMB``: 299xx" #: ../../rst/dev_guide/developing_modules_general_windows.rst:154 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 "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 では使用できません。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:164 msgid "Windows new module development" msgstr "Windows 新しいモジュール開発" #: ../../rst/dev_guide/developing_modules_general_windows.rst:166 msgid "When creating a new module there are a few things to keep in mind:" msgstr "新しいモジュールを作成する際には、以下の点に留意してください。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:168 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:169 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:170 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:171 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:172 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:173 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:174 msgid "Try and catch specific exceptions when using try/catch statements" msgstr "Try/catch 文の使用時に特定の例外を試して捕え (キャッチし) ます。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:175 msgid "Avoid using PSCustomObjects unless necessary" msgstr "必要な場合を除き PSCustomObject は使用しないでください。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:176 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:177 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:178 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:179 msgid "Ensure the code runs under Powershell v3 and higher on Windows Server 2008 and higher; if higher minimum Powershell or OS versions are required, ensure the documentation reflects this clearly" msgstr "このコードが Windows Server 2008 以降の Powershell v3 以降で動作することを確認してください。最小バージョンより新しい Powershell または OS が必要な場合は、ドキュメントにこの内容が明確に反映されていることを確認してください。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:180 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:181 msgid "Favor native Powershell cmdlets over executable calls if possible" msgstr "可能であれば、実行可能な呼び出しよりも、ネイティブの Powershell コマンドレットを優先してください。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:182 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:183 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:185 msgid "A very basic Powershell module `win_environment `_ 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 `_ が、Powershell モジュールのベストプラクティスが組み込まれています。これは、check-mode および diff-support を実装する方法を示し、特定の条件が満たされるとユーザーに警告を表示します。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:187 msgid "A slightly more advanced module is `win_uri `_ 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 `_ がありますが、ここで、さまざまなパラメーター型 (bool、str、int、list、dict、path) の使用方法やパラメーターの選択方法、モジュールを失敗させる方法、例外の処理方法などを紹介しています。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:189 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:192 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:193 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:194 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:195 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:199 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:197 msgid "The first element is the module option to check the value against" msgstr "最初の要素は、値を確認するモジュールオプションです。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:198 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:199 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:200 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:201 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:202 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:203 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:205 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:209 msgid "``aliases``: A list of aliases for the module option" msgstr "``aliases``: モジュールオプションのエイリアス一覧" #: ../../rst/dev_guide/developing_modules_general_windows.rst:210 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`` の場合は、各リストの値が choices に対して検証され、リスト自体は検証されません。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:211 msgid "``default``: The default value for the module option if not set" msgstr "``default``: モジュールオプションのデフォルト値 (設定されていない場合) です。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:212 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:213 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:214 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:215 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:216 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:217 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:218 msgid "``required``: Will fail when the module option is not set" msgstr "``required``: モジュールオプションが設定されていない場合は失敗します。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:229 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:220 msgid "``bool``: A boolean value" msgstr "``bool``: ブール値です。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:221 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:222 msgid "``float``: A float or `Single `_ value" msgstr "``float``: 浮動 または `Single `_ の値" #: ../../rst/dev_guide/developing_modules_general_windows.rst:223 msgid "``int``: An Int32 value" msgstr "``int``: Int32 値です。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:224 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:225 msgid "``list``: A list of values, ``elements=`` 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=``) が設定されている場合は、個々のリスト値タイプを変換できます。``elements=dict`` で、``options``が定義されている場合、値は引数の仕様に対して検証されます。入力が文字列である場合、文字列は ``,`` で分割され、空白文字はすべてトリミングされます。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:226 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:227 msgid "``raw``: No conversions occur on the value passed in by Ansible" msgstr "``raw``: Ansible によって渡される値で変換が行われません。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:228 msgid "``sid``: Will convert Windows security identifier values or Windows account names to a `SecurityIdentifier `_ value" msgstr "``sid``: Windows セキュリティー識別子の値または Windows アカウント名を `SecurityIdentifier `_ 値に変換します。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:229 msgid "``str``: The value is converted to a string" msgstr "``str``: この値は文字列に変換されます。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:231 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:233 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:234 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:235 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:236 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:237 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:238 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:239 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:241 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:251 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:254 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:257 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:258 msgid ".NET classes like ``[System.IO.Path]::GetRandomFileName()``" msgstr "``[System.IO.Path]::GetRandomFileName()`` などの .NET クラス" #: ../../rst/dev_guide/developing_modules_general_windows.rst:259 msgid "WMI objects through the ``New-CimInstance`` cmdlet" msgstr "``New-CimInstance`` コマンドレッド経由の WMI オブジェクト" #: ../../rst/dev_guide/developing_modules_general_windows.rst:260 msgid "COM objects through ``New-Object -ComObject`` cmdlet" msgstr "``New-Object -ComObject`` cmdlet 経由の COM オブジェクト" #: ../../rst/dev_guide/developing_modules_general_windows.rst:261 msgid "Calls to native executables like ``Secedit.exe``" msgstr "``Secedit.exe``など、ネイティブ実行可能ファイルへの呼び出し" #: ../../rst/dev_guide/developing_modules_general_windows.rst:263 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:271 msgid "These are the checks that can be used within Ansible modules:" msgstr "以下のチェックは、Ansible モジュール内で使用できます。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:273 msgid "``#Requires -Module Ansible.ModuleUtils.``: Added in Ansible 2.4, specifies a module_util to load in for the module execution." msgstr "``#Requires -Module Ansible.ModuleUtils.``: Ansible 2.4 で追加され、モジュール実行のために読み込む module_util を指定します。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:274 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:275 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:276 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:277 msgid "``#AnsibleRequires -CSharpUtil Ansible.``: Added in Ansible 2.8, specifies a C# module_util to load in for the module execution." msgstr "``#AnsibleRequires -CSharpUtil Ansible.``: Ansible 2.8 で追加され、モジュール実行のために読み込む C# module_util を指定します。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:279 msgid "C# module utils can reference other C# utils by adding the line ``using Ansible.;`` to the top of the script with all the other using statements." msgstr "C# モジュールユーティリティーは、すべてのステートメントを使用し、スクリプトの上部に ``using Ansible.;`` 行を追加することで、他の C# ユーティリティーを参照できます。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:285 msgid "Windows module utilities" msgstr "Windows モジュールユーティリティー" #: ../../rst/dev_guide/developing_modules_general_windows.rst:287 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:295 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:305 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:314 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:317 msgid "``//AssemblyReference -Name [-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 [-CLR [Core|Framework]]``: コンパイル中に参照するアセンブリー DLL です。任意の ``-CLR`` フラグを使用して、.NET Core、Framework、またはその両方 (省略されている場合) で実行するときに参照するかどうかを表示することもできます。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:318 msgid "``//NoWarn -Name [-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 `_" msgstr "``//NoWarn -Name [-CLR [Core|Framework]]``: コードをコンパイルするときに無視するコンパイラ警告 ID で、任意の ``-CLR`` が上記と同じように機能します。警告のリストは、`コンパイラーエラー `_ で見つけることができます。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:320 msgid "As well as this, the following pre-processor symbols are defined;" msgstr "この他に、以下のプリプロセッサーシンボルも定義されています。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:322 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:323 msgid "``WINDOWS``: This symbol is present when PowerShell is running on Windows" msgstr "``WINDOWS``: このシンボルは、PowerShell が Windows で実行している場合に表示されます。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:324 msgid "``UNIX``: This symbol is present when PowerShell is running on Unix" msgstr "``UNIX``: このシンボルは、PowerShell が Unix で実行している場合に表示されます。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:326 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:347 msgid "The following is a list of module_utils that are packaged with Ansible and a general description of what they do:" msgstr "以下に Ansible と一緒にパッケージ化されている module_utils リストと、それらの機能の一般的な説明です。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:350 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:351 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:352 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:353 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:354 msgid "Legacy: General definitions and helper utilities for Ansible module." msgstr "Legacy: Ansible モジュールの一般的な定義およびヘルパーユーティリティー。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:355 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:356 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:358 msgid "For more details on any specific module utility and their requirements, please see the `Ansible module utilities source code `_." msgstr "特定のモジュールユーティリティーとその要件に関する詳細は、`Ansible モジュールユーティリティーのソースコード `_ を参照してください。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:361 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:366 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:370 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 のカスタム module_utils (``Ansible.ModuleUtils.ModuleUtil1``、``Ansible.ModuleUtils.ModuleUtil2``、および名前空間を含むC# ユーティリティー ``Ansible.CustomUtil``) を含むロール構造です。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:385 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 の各 module_util には、ファイルの終わりに ``Export-ModuleMember`` でエクスポートされた関数が少なくとも 1 つ含まれている必要があります。以下に例を示します。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:394 msgid "Exposing shared module options" msgstr "共有モジュールオプションの公開" #: ../../rst/dev_guide/developing_modules_general_windows.rst:396 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:401 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:405 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:408 msgid "A ``Get-Spec`` function that outputs the common spec for a module" msgstr "モジュールの共通の仕様を出力する ``Get-Spec`` 関数" #: ../../rst/dev_guide/developing_modules_general_windows.rst:408 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:409 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:410 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:412 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:417 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:420 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:476 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:503 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:508 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:514 msgid "Windows playbook module testing" msgstr "Windows Playbook モジュールのテスト" #: ../../rst/dev_guide/developing_modules_general_windows.rst:516 msgid "You can test a module with an Ansible playbook. For example:" msgstr "以下のように、Ansible Playbook でモジュールをテストできます。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:518 msgid "Create a playbook in any directory ``touch testmodule.yml``." msgstr "任意のディレクトリーに Playbook を作成します (``touch testmodule.yml``)。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:519 msgid "Create an inventory file in the same directory ``touch hosts``." msgstr "同じディレクトリー ``touch hosts`` にインベントリーファイルを作成します。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:520 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:531 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:533 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:539 msgid "Windows debugging" msgstr "Windows のデバッグ" #: ../../rst/dev_guide/developing_modules_general_windows.rst:541 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:545 msgid "Copy the module script to the Windows server" msgstr "モジュールスクリプトを Windows サーバーにコピーします。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:546 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:547 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:548 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:580 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:592 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:595 msgid "`Powershell ISE`_" msgstr "`Powershell ISE`_" #: ../../rst/dev_guide/developing_modules_general_windows.rst:596 msgid "`Visual Studio Code`_" msgstr "`Visual Studio Code`_" #: ../../rst/dev_guide/developing_modules_general_windows.rst:601 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:604 msgid "Prefix the Ansible command with :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1` to specify that Ansible should keep the exec files on the server." msgstr "Ansible コマンドの前に :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1` を付けて、Ansible が exec ファイルをサーバ上に保持するように指定します。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:605 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:606 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:607 msgid "Inside this folder, open the PowerShell script for the module." msgstr "このフォルダー内で、モジュールの PowerShell スクリプトを開きます。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:608 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:612 msgid "Windows unit testing" msgstr "Windows のユニットテスト" #: ../../rst/dev_guide/developing_modules_general_windows.rst:614 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:618 msgid "Windows integration testing" msgstr "Windows 統合テスト" #: ../../rst/dev_guide/developing_modules_general_windows.rst:620 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:624 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:627 msgid "Run the command ``source ./hacking/env-setup`` to prepare environment." msgstr "環境を準備するには、``source ./hacking/env-setup`` コマンドを実行します。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:628 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:629 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:630 msgid ":ref:`Install the required Python modules ` to support WinRM and a configured authentication method." msgstr "WinRM と、設定された認証方法をサポートするのに :ref:`必要な Python モジュールをインストール ` します。" #: ../../rst/dev_guide/developing_modules_general_windows.rst:631 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:633 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:637 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:690 msgid "Windows communication and development support" msgstr "Windows の通信および開発サポート" #: ../../rst/dev_guide/developing_modules_general_windows.rst:692 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 開発に関する議論を行うこと。" #: ../../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-base and provide a seamless user experience." msgstr "この前提条件のリストは、ansible-base で適切に機能し、シームレスなユーザーエクスペリエンスを提供する高品質のモジュールを確実に開発できるように設計されています。" #: ../../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+ `." msgstr ":ref:`Python 2.6+ and Python 3.5+ ` をサポートすることが推奨されます。" #: ../../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 `_." msgstr "ユニットテストや統合テストが強く推奨されます。ユニットテストは、外部リソース (クラウドやネットワークデバイスなど) が必要な場合に特に役に立ちます。詳細については、「:ref:`developing_testing`」および「`ワーキンググループのテスト `_」を参照してください。" #: ../../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:49 msgid "Where to get support" msgstr "サポートを受ける場所" #: ../../rst/dev_guide/developing_modules_in_groups.rst:51 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:53 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:55 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:56 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`` では、インタラクティブな対話を行うことができるため、モジュール開発者に最適なものであることが分かっています。" #: ../../rst/dev_guide/developing_modules_in_groups.rst:57 msgid "IRC meetings - Join the various weekly IRC meetings `meeting schedule and agenda page `_" msgstr "IRC ミーティング。様々な IRC ミーティング (毎週) に参加する。「_」を参照してください。" #: ../../rst/dev_guide/developing_modules_in_groups.rst:60 msgid "Required files" msgstr "必須ファイル" #: ../../rst/dev_guide/developing_modules_in_groups.rst:62 msgid "Your collection should include the following files to be usable:" msgstr "コレクションには、使用可能な以下のファイルが含まれているはずです。" #: ../../rst/dev_guide/developing_modules_in_groups.rst:64 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:65 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:66 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:67 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:69 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:71 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`` に参加することを検討してください (「サポートを得る方法」を参照してください)。" #: ../../rst/dev_guide/developing_modules_in_groups.rst:74 msgid "New to git or GitHub" msgstr "git または GitHub をはじめて使用する場合" #: ../../rst/dev_guide/developing_modules_in_groups.rst:76 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:78 msgid "`How to create a fork of ansible/ansible `_" msgstr "`How to create a fork of ansible/ansible `_" #: ../../rst/dev_guide/developing_modules_in_groups.rst:79 msgid "`How to sync (update) your fork `_" msgstr "`How to sync (update) your fork `_" #: ../../rst/dev_guide/developing_modules_in_groups.rst:80 msgid "`How to create a Pull Request (PR) `_" msgstr "`How to create a Pull Request (PR) `_" #: ../../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 `." msgstr "``PluginLoader`` により読み込まれ、モジュールが使用できる Python オブジェクトとして返すには、Python でプラグインを作成する必要があります。プラグインはコントローラーで実行するため、:ref:`互換性のある Python バージョン ` で作成する必要があります。" #: ../../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 "Check the different `AnsibleError objects `_ and see which one applies best to your situation." msgstr "様々な `AnsibleError オブジェクト `_ を確認して、お使いの状況に最適なものを確認します。" #: ../../rst/dev_guide/developing_plugins.rst:42 msgid "String encoding" msgstr "文字列エンコーディング" #: ../../rst/dev_guide/developing_plugins.rst:44 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:52 msgid "Plugin configuration & documentation standards" msgstr "プラグインの設定およびドキュメントの標準仕様" #: ../../rst/dev_guide/developing_plugins.rst:54 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`` セクションで記述します。Ansible バージョン 2.4 以降、コールバックおよび接続プラグインはこの方法で設定要件を宣言しました。ほとんどのプラグインが同じように動作するようになりました。この方法により、プラグインのオプションのドキュメントを常に正しく最新の状態に保つことができます。設定可能なオプションをプラグインに追加するには、以下の形式で定義します。" #: ../../rst/dev_guide/developing_plugins.rst:71 msgid "To access the configuration settings in your plugin, use ``self.get_option()``. For most plugin types, the controller pre-populates the settings. If you need to populate settings explicitly, use a ``self.set_options()`` call." msgstr "プラグインの設定にアクセスするには、``self.get_option()`` を使用します。ほとんどのプラグインタイプでは、コントローラーは設定を事前に設定します。設定を明示的に設定する必要がある場合は、``self.set_options()`` 呼び出しを使用します。" #: ../../rst/dev_guide/developing_plugins.rst:73 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:76 msgid "Developing particular plugin types" msgstr "特定のプラグインタイプの開発" #: ../../rst/dev_guide/developing_plugins.rst:81 #: ../../rst/dev_guide/developing_program_flow_modules.rst:24 msgid "Action plugins" msgstr "Action プラグイン" #: ../../rst/dev_guide/developing_plugins.rst:83 msgid "Action plugins let you integrate local processing and local data with module functionality." msgstr "Action プラグインを使用すると、ローカル処理とローカルデータをモジュール機能に統合できます。" #: ../../rst/dev_guide/developing_plugins.rst:85 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:94 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:104 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:141 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:144 msgid "For practical examples of action plugins, see the source code for the `action plugins included with Ansible Core `_" msgstr "action プラグインの実際の例は、`Ansible Core に同梱される action プラグイン `_ のソースコードを参照してください。" #: ../../rst/dev_guide/developing_plugins.rst:150 msgid "Cache plugins" msgstr "Cache プラグイン" #: ../../rst/dev_guide/developing_plugins.rst:152 msgid "Cache plugins store gathered facts and data retrieved by inventory plugins." msgstr "Cache プラグインは、Inventory \\プラグインによって取得されるファクトおよびデータを収集したデータを格納します。" #: ../../rst/dev_guide/developing_plugins.rst:154 msgid "Import cache plugins using the cache_loader so you can use ``self.set_options()`` and ``self.get_option()``. 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()`` を使用できる cache_loader を使用する cache プラグインをインポートします。コードベースで Cache プラグインを直接インポートする場合は、``ansible.constants`` からのみオプションにアクセスでき、Inventory プラグインによって使用される cache プラグインの機能が壊れます。" #: ../../rst/dev_guide/developing_plugins.rst:162 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:164 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()`` should be used to access cache options." msgstr "キャッシュプラグインを作成するには、適切なベースクラスで新しい ``CacheModule`` クラスを作成して開始します。``__init__`` メソッドを使用してプラグインを作成する場合は、指定された arg および kwarg でベースクラスを初期化し、インベントリープラグインキャッシュオプションと互換性がある必要があります。ベースクラスは ``self.set_options(direct=kwargs)`` を呼び出します。ベースクラス ``__init__`` メソッドが ``self.get_option()`` を呼び出したあと、キャッシュオプションにアクセスする必要があります。" #: ../../rst/dev_guide/developing_plugins.rst:166 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:179 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:181 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`` を使用する場合は、ベースクラスメソッド ``_load`` および ``_dump`` から呼び出される ``_load`` メソッドおよび ``_dump`` メソッドを実装する必要があります。" #: ../../rst/dev_guide/developing_plugins.rst:183 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`` メソッドを使用します。" #: ../../rst/dev_guide/developing_plugins.rst:185 msgid "For example cache plugins, see the source code for the `cache plugins included with Ansible Core `_." msgstr "cache プラグインの例は、`Ansible Core に同梱される cache プラグイン `_ のソースコードを参照してください。" #: ../../rst/dev_guide/developing_plugins.rst:190 msgid "Callback plugins" msgstr "Callback プラグイン" #: ../../rst/dev_guide/developing_plugins.rst:192 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:194 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:203 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 `_ directory." msgstr "そこから、コールバックを提供する CallbackBase から特定のメソッドを上書きします。Ansible バージョン 2.0 以降で使用するプラグインでは、``v2`` で始まる方法のみを上書きしてください。上書きできるメソッドの完全なリストは、`lib/ansible/plugins/callback `_ ディレクトリーの ``__init__.py`` を参照してください。" #: ../../rst/dev_guide/developing_plugins.rst:208 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:277 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:279 msgid "For example callback plugins, see the source code for the `callback plugins included with Ansible Core `_" msgstr "callback プラグインの例は、`Ansible Core に同梱される callback プラグイン `_ のソースコードを参照してください。" #: ../../rst/dev_guide/developing_plugins.rst:281 msgid "New in ansible-base 2.11, callback plugins are notified (via ``v2_playbook_on_task_start``) of :ref:`meta` tasks. By default, only explicit ``meta`` tasks that users list in their plays are sent to callbacks." msgstr "ansible-base 2.11 の新機能として、:ref:`meta` タスクのコールバックプラグインが (``v2_playbook_on_task_start`` を介して) 通知されます。デフォルトでは、プレイに上あげる明示的な ``meta`` タスクのみが、コールバックに送信されます。" #: ../../rst/dev_guide/developing_plugins.rst:283 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:288 msgid "Connection plugins" msgstr "Connection プラグイン" #: ../../rst/dev_guide/developing_plugins.rst:290 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 "接続プラグインにより、Ansible はターゲットホストに接続してそのホストにあるタスクを実行できるようにします。Ansible には多くの接続プラグインが同梱されていますが、一度に使用できるのは 1 つのみとなります。最も一般的に使用される接続プラグインは、``paramiko`` SSH、ネイティブ ssh (単に ``ssh`` と呼ばれる)、および ``local`` 接続タイプです。これらはすべて Playbook で使用され、``/usr/bin/ansible`` を使用してリモートマシンに接続します。" #: ../../rst/dev_guide/developing_plugins.rst:292 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`` 接続プラグインが導入されます。``smart`` 接続タイプにより、Ansible は、システム機能に基づいて、``paramiko`` 接続プラグインまたは ``openssh`` 接続プラグインのいずれかを自動的に選択できますが、OpenSSH が ControlPersist に対応している場合は ``ssh`` の Connetion プラグインを選択します。" #: ../../rst/dev_guide/developing_plugins.rst:294 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 `." msgstr "新しい connetion プラグイン (SNMP、メッセージバス、またはその他のトランスポートをサポートする場合など) を作成するには、既存の connetion プラグインのいずれかの形式をコピーして、:ref:`ローカルプラグインパス ` にある ``connection`` ディレクトリーに置きます。" #: ../../rst/dev_guide/developing_plugins.rst:296 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 "接続プラグインは、属性名 (ここでは ``timeout``) のドキュメントでエントリーを定義することで、一般的なオプション (``--timeout`` フラグなど) をサポートします。一般的なオプションには null 以外のデフォルトがある場合、別のデフォルトは無視されるため、プラグインは同じデフォルトを定義する必要があります。" #: ../../rst/dev_guide/developing_plugins.rst:298 msgid "For example connection plugins, see the source code for the `connection plugins included with Ansible Core `_." msgstr "選択プラグインの例は、`Ansible Core に同梱される接続プラグイン `_ のソースコードを参照してください。" #: ../../rst/dev_guide/developing_plugins.rst:303 msgid "Filter plugins" msgstr "Filter プラグイン" #: ../../rst/dev_guide/developing_plugins.rst:305 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:307 msgid "Filter plugins do not use the standard configuration and documentation system described above." msgstr "Filter プラグインは、上記の標準設定およびドキュメントシステムを使用しません。" #: ../../rst/dev_guide/developing_plugins.rst:309 msgid "For example filter plugins, see the source code for the `filter plugins included with Ansible Core `_." msgstr "vars プラグインの例は、`Ansible Core に同梱される filter プラグイン `_ のソースコードを参照してください。" #: ../../rst/dev_guide/developing_plugins.rst:316 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:318 msgid "You can see the details for inventory plugins in the :ref:`developing_inventory` page." msgstr "インベントリープラグインの詳細は、:ref:`developing_inventory` ページを参照してください。" #: ../../rst/dev_guide/developing_plugins.rst:323 msgid "Lookup plugins" msgstr "Lookup プラグイン" #: ../../rst/dev_guide/developing_plugins.rst:325 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:327 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 つ記述してください。" #: ../../rst/dev_guide/developing_plugins.rst:329 msgid "Ansible includes many :ref:`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 ` が多数含まれています。Lookup プラグイン内でフィルタリングを行うことが理にかなっている場合もあれば、Playbook でフィルタリングできる結果を返す方がよい場合もあります。Lookup プラグイン内で実行する適切なフィルタリングレベルを決定するときは、データがどのように参照されるかに留意してください。" #: ../../rst/dev_guide/developing_plugins.rst:331 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:393 msgid "The following is an example of how this lookup is called:" msgstr "以下は、このルックアップがどのように呼び出されるかの例になります。" #: ../../rst/dev_guide/developing_plugins.rst:408 msgid "For example lookup plugins, see the source code for the `lookup plugins included with Ansible Core `_." msgstr "vars プラグインの例は、`Ansible Core に同梱される lookup プラグイン `_ のソースコードを参照してください。" #: ../../rst/dev_guide/developing_plugins.rst:410 msgid "For more usage examples of lookup plugins, see :ref:`Using Lookups`." msgstr "検索プラグインのその他の使用例については、「:ref:`検索の使用`」を参照してください。" #: ../../rst/dev_guide/developing_plugins.rst:415 msgid "Test plugins" msgstr "Test プラグイン" #: ../../rst/dev_guide/developing_plugins.rst:417 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`` などのフィルタープラグインと組み合わせて使うと特に便利です。また、``when:`` などの条件付きディレクティブにも利用できます。" #: ../../rst/dev_guide/developing_plugins.rst:419 msgid "Test plugins do not use the standard configuration and documentation system described above." msgstr "Test プラグインは、上記の標準設定およびドキュメントシステムを使用しません。" #: ../../rst/dev_guide/developing_plugins.rst:421 msgid "For example test plugins, see the source code for the `test plugins included with Ansible Core `_." msgstr "test プラグインの例は、`Ansible Core に同梱されるテストプラグイン `_ のソースコードを参照してください。" #: ../../rst/dev_guide/developing_plugins.rst:426 msgid "Vars plugins" msgstr "Vars プラグイン" #: ../../rst/dev_guide/developing_plugins.rst:428 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:430 msgid "Vars plugins were partially implemented in Ansible 2.0 and rewritten to be fully implemented starting with Ansible 2.4. Vars plugins are unsupported by collections." msgstr "vars プラグインは Ansible 2.0 に部分的に実装され、Ansible 2.4 以降では、完全実装になるように書き直されました。vars プラグインはコレクションによりサポートされません。" #: ../../rst/dev_guide/developing_plugins.rst:432 msgid "Older plugins used a ``run`` method as their main body/work:" msgstr "古いプラグインでは、``run`` メソッドを主要な本文/作業として使用していました。" #: ../../rst/dev_guide/developing_plugins.rst:440 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:448 msgid "The parameters are:" msgstr "パラメーターは以下のとおりです。" #: ../../rst/dev_guide/developing_plugins.rst:450 msgid "loader: Ansible's DataLoader. The DataLoader can read files, auto-load JSON/YAML and decrypt vaulted data, and cache read files." msgstr "DataLoader は、ファイルの読み取り、JSON/YAML の自動読み込み、vault を使用したデータの復号化、および読み取りファイルのキャッシュを行うことができます。" #: ../../rst/dev_guide/developing_plugins.rst:451 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:452 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:454 msgid "This ``get_vars`` method just needs to return a dictionary structure with the variables." msgstr "この ``get_vars`` メソッドは変数を含むディクショナリー構造を返す必要があります。" #: ../../rst/dev_guide/developing_plugins.rst:456 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:458 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`` を設定します。" #: ../../rst/dev_guide/developing_plugins.rst:465 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:485 msgid "For example vars plugins, see the source code for the `vars plugins included with Ansible Core `_." msgstr "vars プラグインの例は、`Ansible Core に含まれる vars プラグイン `_ のソースコードを参照してください。" #: ../../rst/dev_guide/developing_plugins.rst:495 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-base`` 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-base`` コードを使用している場合、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 "アクションプラグインは、Playbook を作成する人にとってはモジュールのように見えます。ほとんどのアクションプラグインの使用方法に関するドキュメントは、同じ名前のモジュール内にあります。アクションプラグインの中には、すべての作業を行なうものもありますが、このモジュールはドキュメントのみを提供します。一部のアクションプラグインはモジュールを実行します。``normal`` アクションプラグインは、特別なアクションプラグインを持たないモジュールを実行します。アクションプラグインは常にコントローラーで実行します。" #: ../../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 ` action plugin (which prints text for the user to see) and the :ref:`assert ` action plugin (which tests whether values in a playbook satisfy certain criteria) execute entirely on the controller." msgstr "アクションプラグインによってコントローラーですべての作業が機能します。たとえば、:ref:`debug ` アクションプラグイン (ユーザーのテキストを出力する) および :ref:`assert ` アクションプラグイン (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 ` 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 ` which operates on the remote system to move the file into its final location, sets file permissions, and so on." msgstr "ほとんどのアクションプラグインは、コントローラーにいくつかの値を設定した後、管理ノードで実際のモジュールを呼び出して、これらの値を使用して何かを行います。たとえば、:ref:`template ` アクションプラグインは、ユーザーから値を受け取り、Playbook 環境からの変数を使用して、コントローラーの一時的な場所にファイルを作成します。その後、その一時ファイルをリモートシステム上の一時ファイルに転送します。その後、リモートシステム上で動作する :ref:`copy モジュール ` を起動して、ファイルを最終的な場所に移動させ、ファイルのパーミッションを設定するなどの作業を行います。" #: ../../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`、およびさまざまなファイル操作として取得します。" #: ../../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 ``<>`` 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 "これらのモジュールは、本文に文字列 ``<>`` が含まれるスクリプトです。この文字列は 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 ` or :ref:`Old-style module ` instead." msgstr "Ansible は、:term:`JSON` の文字列を引用符なしで出力します。文字列値の引用には二重引用符が使用され、文字列値の中の二重引用符はバックスラッシュでエスケープされ、文字列値の中の一重引用符はエスケープされずに表示されることがあります。JSONARGS を使用するには、スクリプト言語がこの種の文字列を処理する方法を備えている必要があります。この例では、Python の三重引用符文字列を使用しています。他のスクリプト言語では、JSON 内の引用符と混同されないような同様の引用符文字が用意されていたり、独自の引用開始文字や引用終了文字を定義できたりする場合があります。お使いの言語がこれを提供していない場合は、代わりに :ref:`非ネイティブ JSON モジュール ` または :ref:`古いスタイルのモジュール ` を記述する必要があります。" #: ../../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 `_ repository." msgstr "Ruby で書かれた非ネイティブモジュールの例は、`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 `." msgstr "バイナリモジュールは、引数を取り、:ref:`want JSON モジュール ` と同じ方法でデータを Ansible に返します。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:144 msgid "One example of a `binary module `_ written in go." msgstr "Go で書かれた `binary module `_ バイナリーモジュールの一例" #: ../../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 `, 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 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 ` (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 `. If it's a module, it loads the :ref:`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 ` (:command:`/usr/bin/ansible` の場合はコマンドライン) から解析されたモジュール名とパラメーターを受け取ります。これは、モジュールを見て、または :ref:`Action Plugin ` を見ているかを判断するために名前を使用します。モジュールの場合は、:ref:`Normal Action Plugin ` を読み込み、タスクとプレイに関する名前、変数、およびその他の情報をそのアクションプラグインに渡して、さらに処理します。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:186 msgid "The ``normal`` action plugin" msgstr "``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 "``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 "タスクに適切な接続プラグインを読み込み、そのホストへの接続を作成するために必要に応じて転送や実行を行います。" #: ../../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 ` code described in the next section decides which format those will take." msgstr "これに、モジュールおよびモジュールパラメーターがリモートホストにプッシュされますが、次のセクションで説明する :ref:`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 モジュールの複雑さなど。これにより、他のアクションプラグインからのモジュールの内部呼び出しが機能します)。" #: ../../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 ` 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 は、Auction プラグイン ``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 ` and :ref:`JSON-args modules ` are passed through :ref:`Module Replacer `." msgstr ":ref:`PowerShell ` および :ref:`JSON-args modules ` は、:ref:`Module Replacer ` 経由で渡されます。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:226 msgid "New-style :ref:`Python modules ` are assembled by :ref:`Ansiballz`." msgstr "新しいスタイルの :ref:`Python modules ` は :ref:`Ansiballz` によってアセンブルされます。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:227 msgid ":ref:`Non-native-want-JSON `, :ref:`Binary modules `, and :ref:`Old-Style modules ` aren't touched by either of these and pass through unchanged." msgstr ":ref:`Non-native-want-JSON `、:ref:`バイナリーモジュール `、および:ref:`古いスタイルのモジュール ` は、これらのどちらにも触れられず、変更されずにそのまま通過します。" #: ../../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 ` which continues execution of the module." msgstr "アセンブル手順後、シバン行を持つすべてのモジュールに最終変更が行われます。Ansible は、シバン行内のインタープリターに ``ansible_$X_interpreter`` インベントリー変数を介して特定のパスが設定されているかどうかを確認します。存在する場合には、Ansible は、そのパスを、そのモジュールに指定されているインタープリターパスに置き換えます。その後、Ansible は完全なモジュールデータを返し、モジュールタイプを :ref:`Normal Action ` に返し、モジュールの実行を続行します。" #: ../../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 "モジュールファイルでのみ実行する置換。モジュールは、便利なボイラープレートや引数へのアクセスに使用できるパブリックの置換文字列です。" #: ../../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 `." msgstr ":code:`from ansible.module_utils.MOD_LIB_NAME import *` は、:file:`ansible/module_utils/MOD_LIB_NAME.py` の内容に置き換えます。これらは、:ref:`new-style Python modules ` と併用する必要があります。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:261 msgid ":code:`#<>` is equivalent to :code:`from ansible.module_utils.basic import *` and should also only apply to new-style Python modules." msgstr ":code:`#<>` は、: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 `." msgstr ":code:`# POWERSHELL_COMMON` は、:file:`ansible/module_utils/powershell.ps1` の内容を置き換えます。これは、:ref:`新しいスタイルの Powershell モジュール ` と併用する必要があります。" #: ../../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:`\"<>\"` is substituted with the Ansible version. In :ref:`new-style 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 バージョンに置き換えられます。:ref:`Ansiballz` フレームワークの下の :ref:`new-style Python modules ` で適切な方法は、代わりに `AnsibleModule` をインスタンス化したと、:attr:``AnsibleModule.ansible_version`` からバージョンにアクセスすることです。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:275 msgid ":code:`\"<>\"` 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:`\"<>\"` は、:term:`JSON` でエンコードされたモジュールパラメーターの Python ``repr`` の文字列に置き換えます。JSON 文字列で ``repr`` を使用すると、Python ファイルに安全に埋め込むことができます。Ansiballz フレームワークの新しいスタイル Python モジュールでは、`AnsibleModule` をインスタンス化してから :attr:`AnsibleModule.params` を使用することで、これはより適切にアクセスされます。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:281 msgid ":code:`<>` 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 にファイルシステムに依存するファイルシステムのカンマ区切りの一覧である文字列を置き換えます。新しいスタイルの Python モジュールで `AnsibleModule` をインスタンス化してから、:attr:`AnsibleModule._selinux_special_fs` を使用してください。また、この変数は、ファイルシステム名のカンマ区切りの文字列から、実際の python のリストに変更されています。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:288 msgid ":code:`<>` 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:`<>` はモジュールパラメーターを 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 ` for details." msgstr "文字列 :code:`syslog.LOG_USER` は、:file:`ansible.cfg` またはこのホストに適用される ``ansible_syslog_facility`` インベントリー変数で囲まれている ``syslog_facility`` に置き換えられます。新しいスタイルの Python モジュールでは、これは若干変更になりました。本当にアクセスする必要がある場合は、`AnsibleModule` をインスタンス化し、その後 :attr:`AnsibleModule._syslog_facility` を使用してアクセスする必要があります。これは実際の syslog 機能ではなく、syslog 機能の名前になります。詳細は、:ref:`documentation on 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` のファイル、およびモジュールのパラメーターを渡すボイラープレートが含まれます。その後、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:`#<>` 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:`#<>` のインスタンスは :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 "モジュールを作成している場合は、引数を渡す方法は内部実装の詳細であることに注意してください。これは過去に変更されており、共通の module_utils コードを変更すると、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 `_ for an example." msgstr "ここに記載されている内部引数はグローバルです。カスタムモジュールにローカルの内部引数を追加する必要がある場合は、その特定のモジュール用のアクションプラグインを作成してください。例は、「`copy action plugin `_」の「``_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:434 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:438 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:445 msgid "_ansible_syslog_facility" msgstr "_ansible_syslog_facility" #: ../../rst/dev_guide/developing_program_flow_modules.rst:447 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:468 msgid "_ansible_version" msgstr "_ansible_version" #: ../../rst/dev_guide/developing_program_flow_modules.rst:470 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:482 msgid "Module return values & Unsafe strings" msgstr "モジュール戻り値と安全でない文字列" #: ../../rst/dev_guide/developing_program_flow_modules.rst:484 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) に出力します。normal アクションプラグインは JSON 文字列を受け取り、Python ディクショナリーに解析してエクゼキューターに返します。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:486 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:488 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()`` を介してモジュールを呼び出して返された文字列には、normal アクションプラグインによって自動的に ``Unsafe`` というマークが付きます。別のアクションプラグインが他の方法でモジュールから情報を取得した場合は、そのアクションプラグイン自身がその戻り値に ``Unsafe`` マークを付ける必要があります。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:490 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 "不適切にコーディングされたアクションプラグインが結果を「Unsafe」と表示しなかった場合、Ansible は実行者に返される際に結果を再度監査し、すべての文字列を ``Unsafe`` と表示します。通常のアクションプラグインは、自分自身と、結果データをパラメーターとして呼び出した他のコードを保護します。エクゼキュータ内のチェックは、他のすべてのアクションプラグインの出力を保護し、Ansible が実行する後続のタスクがこれらの結果から何かをテンプレート化することがないようにします。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:496 msgid "Special considerations" msgstr "特別な考慮事項" #: ../../rst/dev_guide/developing_program_flow_modules.rst:501 msgid "Pipelining" msgstr "パイプライン" #: ../../rst/dev_guide/developing_program_flow_modules.rst:503 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:505 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:508 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:511 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:519 msgid "Why pass args over stdin?" msgstr "標準入力 (stdin) で引数を渡す理由" #: ../../rst/dev_guide/developing_program_flow_modules.rst:521 msgid "Passing arguments via stdin was chosen for the following reasons:" msgstr "以下の理由により、stdin で引数を渡すことが選択されました。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:523 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:527 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:529 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:537 msgid "AnsibleModule" msgstr "AnsibleModule" #: ../../rst/dev_guide/developing_program_flow_modules.rst:542 msgid "Argument spec" msgstr "引数の仕様" #: ../../rst/dev_guide/developing_program_flow_modules.rst:544 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:546 msgid "Example ``argument_spec``:" msgstr "``argument_spec`` の例:" #: ../../rst/dev_guide/developing_program_flow_modules.rst:562 msgid "This section will discuss the behavioral attributes for arguments:" msgstr "本セクションでは、引数の動作属性を説明します。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:566 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:568 msgid "str" msgstr "str" #: ../../rst/dev_guide/developing_program_flow_modules.rst:569 msgid "list" msgstr "list" #: ../../rst/dev_guide/developing_program_flow_modules.rst:570 msgid "dict" msgstr "dict" #: ../../rst/dev_guide/developing_program_flow_modules.rst:571 msgid "bool" msgstr "bool" #: ../../rst/dev_guide/developing_program_flow_modules.rst:572 msgid "int" msgstr "int" #: ../../rst/dev_guide/developing_program_flow_modules.rst:573 msgid "float" msgstr "float" #: ../../rst/dev_guide/developing_program_flow_modules.rst:574 msgid "path" msgstr "path" #: ../../rst/dev_guide/developing_program_flow_modules.rst:575 msgid "raw" msgstr "raw" #: ../../rst/dev_guide/developing_program_flow_modules.rst:576 msgid "jsonarg" msgstr "jsonarg" #: ../../rst/dev_guide/developing_program_flow_modules.rst:577 #: ../../rst/dev_guide/style_guide/index.rst:150 msgid "json" msgstr "json" #: ../../rst/dev_guide/developing_program_flow_modules.rst:578 msgid "bytes" msgstr "bytes" #: ../../rst/dev_guide/developing_program_flow_modules.rst:579 msgid "bits" msgstr "bits" #: ../../rst/dev_guide/developing_program_flow_modules.rst:581 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:585 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:589 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:593 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 つ目の引数は、呼び出し可能な値のリストを指定します。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:595 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:605 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:609 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:613 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:616 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:620 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:624 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:628 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:630 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:634 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`` で使用する必要があります。" #: ../../rst/dev_guide/developing_program_flow_modules.rst msgid "removed_at_date" msgstr "removed_at_date" #: ../../rst/dev_guide/developing_program_flow_modules.rst:648 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`` と一緒に使用する必要があります。" #: ../../rst/dev_guide/developing_program_flow_modules.rst msgid "removed_from_collection" msgstr "removed_from_collection" #: ../../rst/dev_guide/developing_program_flow_modules.rst:662 msgid "Specifies which collection (or ansible-base) deprecates this deprecated argument. Specify ``ansible.builtin`` for ansible-base, or the collection's name (format ``foo.bar``). Must be used with ``removed_in_version`` or ``removed_at_date``." msgstr "この非推奨の引数を非推奨にするコレクション (または ansible-base) を指定します。ansible-base には ``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:666 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:670 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:674 msgid "The version of ansible-base or the collection this alias will be removed in. Either ``version`` or ``date`` must be specified." msgstr "ansible-base、またはこのエイリアスは削除されるコレクションのバージョン。``version`` または ``date`` のいずれかを指定する必要があります。" #: ../../rst/dev_guide/developing_program_flow_modules.rst msgid "date" msgstr "date" #: ../../rst/dev_guide/developing_program_flow_modules.rst:678 msgid "The a date after which a minor release of ansible-base or a major collection release will no longer contain this alias.. Either ``version`` or ``date`` must be specified." msgstr "ansible-base のマイナーリリースまたはメジャーコレクションリリースにこのエイリアスが含まれなくなった日付。``version`` または ``date`` のいずれかを指定する必要があります。" #: ../../rst/dev_guide/developing_program_flow_modules.rst msgid "collection_name" msgstr "collection_name" #: ../../rst/dev_guide/developing_program_flow_modules.rst:682 msgid "Specifies which collection (or ansible-base) deprecates this deprecated alias. Specify ``ansible.builtin`` for ansible-base, or the collection's name (format ``foo.bar``). Must be used with ``version`` or ``date``." msgstr "この非推奨のエイリアスを非推奨にするコレクション (または ansible-base) を指定します。ansible-base には ``ansible.builtin``、またはコレクションの名前 (``foo.bar`` の形式) を指定します。``version`` または ``date`` と共に使用する必要があります。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:684 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:708 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:712 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:716 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:720 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:724 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:730 msgid "Dependencies between module options" msgstr "モジュールオプションの依存関係" #: ../../rst/dev_guide/developing_program_flow_modules.rst:732 msgid "The following are optional arguments for ``AnsibleModule()``:" msgstr "以下は、``AnsibleModule()`` のオプションの引数です。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:748 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:759 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:761 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:765 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:775 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:779 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:789 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:793 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 つの値の値は、3 つまたは 4 つの値でなければなりません。最初の 2 つの値はオプション名と、その条件を説明するオプションの値です。シーケンスの追加要素は、その名前のオプションが正確にこの値を持っている場合にのみ必要です。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:795 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:802 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:817 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:819 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:823 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:834 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:837 msgid "Declaring check mode support" msgstr "チェックモードのサポートの宣言" #: ../../rst/dev_guide/developing_program_flow_modules.rst:839 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:845 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:847 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 () does not support check mode``." msgstr "``supports_check_mode=False`` が指定されている場合 (デフォルト値)、モジュールはチェックモードで ``skipped=True`` および ``remote module () does not support check mode`` メッセージで終了します。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:850 msgid "Adding file options" msgstr "ファイルオプションの追加" #: ../../rst/dev_guide/developing_program_flow_modules.rst:852 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:858 msgid "You can find `a list of all file options here `_. 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 "`a list of all file options here `_ を確認できます。今回は、``DOCUMENTATION`` がドキュメントフラグメント ``ansible.builtin.files`` (:ref:`module_docs_fragments`を参照) を拡張し、これらのフィールドがすべて正しく文書化されていることを確認することが推奨されます。" #: ../../rst/dev_guide/developing_program_flow_modules.rst:860 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-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 で実行されるコードを記述できる必要があります。" #: ../../rst/dev_guide/developing_python_3.rst:13 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 コードのすべてに適用されます。" #: ../../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`" msgstr "コントローラー側のコード: :command:`/usr/bin/ansible` を呼び出すマシンで実行されるコード" #: ../../rst/dev_guide/developing_python_3.rst:17 msgid "modules - the code which Ansible transmits to and invokes on the managed machine." msgstr "モジュール - 管理マシンに Ansible が送信したり起動したりするコード。" #: ../../rst/dev_guide/developing_python_3.rst:18 msgid "shared ``module_utils`` code - the common code that's used by modules to perform tasks and sometimes used by controller-side code as well" msgstr "共有されている ``module_utils`` コード - タスクを実行するためにモジュールが使用する一般的なコードで、コントローラーのコードでも使用されることがあります。" #: ../../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:23 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:25 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 以降をサポートします。" #: ../../rst/dev_guide/developing_python_3.rst:28 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 バージョンが同梱されていました。" #: ../../rst/dev_guide/developing_python_3.rst:33 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 でしか機能しないことを認めています。" #: ../../rst/dev_guide/developing_python_3.rst:42 msgid "Python 2.4 Module-side Support:" msgstr "Python 2.4 モジュールでのサポート:" #: ../../rst/dev_guide/developing_python_3.rst:44 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 リリースでした。" #: ../../rst/dev_guide/developing_python_3.rst:50 msgid "Developing Ansible code that supports Python 2 and Python 3" msgstr "Python 2 および Python 3 をサポートする Ansible コードの開発" #: ../../rst/dev_guide/developing_python_3.rst:52 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 `_. 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 `_" msgstr "Python 2 と Python 3 の両方をサポートするコードの記述について学び始めるのに最適なのは、`Lennart Regebro の著書: Porting to Python 3 `_ です。本書では、Python 3 に移植するためのいくつかの戦略が説明されています。Ansible で使用しているのは、`単一のコードベースから Python 2 および Python 3 をサポートするため `_ です。" #: ../../rst/dev_guide/developing_python_3.rst:59 msgid "Understanding strings in Python 2 and Python 3" msgstr "Python 2 および Python 3 の文字列を理解" #: ../../rst/dev_guide/developing_python_3.rst:61 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:67 msgid "In Python 2, the two types for these (:class:`str ` for bytes and :func:`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 `、テキストの場合は :func:`unicode `) が、しばしば同じ意味で使用されます。ASCII 文字のみを処理する場合は、文字列を組み合わせて比較し、あるタイプから別のタイプに自動的に変換できます。非 ASCII 文字が導入されると、Python 2 は、非 ASCII 文字がどのエンコーディングに含まれるべきかわからないために例外をスローし始めます。" #: ../../rst/dev_guide/developing_python_3.rst:74 msgid "Python 3 changes this behavior by making the separation between bytes (:class:`bytes `) and text (:class:`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 `) とテキスト (:class:`str `) の分離をより厳格にします。Python 3 は 2 つのタイプの結合と比較を試みる際に例外を発生させます。プログラマーは、ある型から別の型に変換し、混在させる必要があります。" #: ../../rst/dev_guide/developing_python_3.rst:79 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:85 msgid "Ansible uses different strategies for working with strings in controller-side code, in :ref: `modules `, and in :ref:`module_utils ` code." msgstr "Ansible は、:ref:`modules ` コードおよび :ref:`module_utils ` コードのコントローラー側のコードで文字列を操作するためにさまざまな戦略を使用します。" #: ../../rst/dev_guide/developing_python_3.rst:91 msgid "Controller string strategy: the Unicode Sandwich" msgstr "コントローラー文字列戦略: Unicode Sandwich" #: ../../rst/dev_guide/developing_python_3.rst:93 msgid "In controller-side code we use a strategy known as the Unicode Sandwich (named after Python 2's :func:`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 "コントローラー側のコードでは、Unicode Sandwich と呼ばれるストラテジーを使用します (名前は Python 2 の :func:`unicode ` テキストタイプに由来します)。Unicode Sandwich の場合、コードと外部の境界 (ファイルやネットワークの IO、環境変数、ライブラリーの呼び出しなど) でバイトを受信することがわかります。これらのバイトをテキストに変換し、コードの内部全体でこれを使用する必要があります。これらの文字列を外部に返す必要がある場合は、最初にテキストをバイトに変換します。これは、上下にバイトの層、その間に変換の層、中央にすべてのテキストタイプからなる「サンドイッチ」を想像してください。" #: ../../rst/dev_guide/developing_python_3.rst:104 msgid "Unicode Sandwich common borders: places to convert bytes to text in controller code" msgstr "Unicode Sandwich の共通の境界: コントローラーコードのテキストにバイトを変換する場所" #: ../../rst/dev_guide/developing_python_3.rst:106 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:111 msgid "Reading and writing to files" msgstr "ファイルの読み取りおよび書き込み" #: ../../rst/dev_guide/developing_python_3.rst:113 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:131 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:135 msgid "Writing to files is the opposite process:" msgstr "ファイルへの書き込みは、その逆の処理です。" #: ../../rst/dev_guide/developing_python_3.rst:144 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:149 msgid "Filesystem interaction" msgstr "ファイルシステムの相互作用" #: ../../rst/dev_guide/developing_python_3.rst:151 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:172 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:183 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:187 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:194 msgid "Interacting with other programs" msgstr "他のプログラムとの対話" #: ../../rst/dev_guide/developing_python_3.rst:196 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:202 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 つは、接続プラグインの ``exec_command`` メソッドです。これらのメソッドは、コマンドで受け取ったテキスト文字列 (およびコマンドへの引数) をバイトに変換し、stdout と stderr をバイト文字列として返します。高レベルの関数 (アクションプラグインの ``_low_level_execute_command``) 出力をテキスト文字列に変換します。" #: ../../rst/dev_guide/developing_python_3.rst:212 msgid "Module string strategy: Native String" msgstr "モジュール文字列戦略: ネイティブ文字列" #: ../../rst/dev_guide/developing_python_3.rst:214 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:220 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:227 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:233 msgid "Module_utils string strategy: hybrid" msgstr "Module_utils 文字列戦略: ハイブリッド" #: ../../rst/dev_guide/developing_python_3.rst:235 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:242 msgid "In ``module_utils`` code:" msgstr "``module_utils`` コードの場合:" #: ../../rst/dev_guide/developing_python_3.rst:244 msgid "Functions **must** accept string parameters as either text strings or byte strings." msgstr "関数は、文字列パラメーターをテキスト文字列かバイト文字列のいずれかで使用できるようにする **必要があります**。" #: ../../rst/dev_guide/developing_python_3.rst:245 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:246 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:248 msgid "Module-utils functions are therefore often very defensive in nature. They convert their string parameters into text (using ``ansible.module_utils._text.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._text.to_native``) or back to the string type that their parameters received." msgstr "したがって、module_utils 関数は、本質的に非常に防御的であることがよくあります。この関数は、関数の先頭で (``ansible.module_utils._text.to_text`` を使用して) 文字列パラメーターをテキストに変換します。作業を行い、(``ansible.module_utils._text.to_native`` を使用して) 戻り値をネイティブの文字列型に変換します。または、パラメーターが受け取った文字列型に戻ります。" #: ../../rst/dev_guide/developing_python_3.rst:255 msgid "Tips, tricks, and idioms for Python 2/Python 3 compatibility" msgstr "Python 2/Python 3 互換のためのヒント、トリック、イディオム" #: ../../rst/dev_guide/developing_python_3.rst:258 msgid "Use forward-compatibility boilerplate" msgstr "前方互換性のあるボイラープレートの使用" #: ../../rst/dev_guide/developing_python_3.rst:260 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 ファイルの先頭に以下のボイラプレートコードを使用してください。" #: ../../rst/dev_guide/developing_python_3.rst:269 msgid "``__metaclass__ = type`` makes all classes defined in the file into new-style classes without explicitly inheriting from :class:`object `." msgstr "``__metaclass__ = type`` は、ファイルで定義されているすべてのクラスを :class:`object ` から明示的に継承することなく、新しいスタイルのクラスにします。" #: ../../rst/dev_guide/developing_python_3.rst:272 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:274 msgid "Makes imports look in :data:`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 ` を検索し、インポートを行うモジュールが存在するディレクトリーをスキップします。インポートを行うモジュールが存在するディレクトリーをコードが使用したい場合は、新しいドット表記があります。" #: ../../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:278 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:280 msgid "Changes :func:`print ` from a keyword into a function." msgstr "キーワードから関数への :func:`print ` の変更" #: ../../rst/dev_guide/developing_python_3.rst:283 msgid "`PEP 0328: Absolute Imports `_" msgstr "`PEP 0328: Absolute Imports `_" #: ../../rst/dev_guide/developing_python_3.rst:284 msgid "`PEP 0238: Division `_" msgstr "`PEP 0238: Division `_" #: ../../rst/dev_guide/developing_python_3.rst:285 msgid "`PEP 3105: Print function `_" msgstr "`PEP 3105: Print function `_" #: ../../rst/dev_guide/developing_python_3.rst:288 msgid "Prefix byte strings with ``b_``" msgstr "バイト文字列のプレフィックス ``b_``" #: ../../rst/dev_guide/developing_python_3.rst:290 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:301 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:306 msgid "Import Ansible's bundled Python ``six`` library" msgstr "Ansible のバンドルされた Python ``six`` ライブラリーをインポート" #: ../../rst/dev_guide/developing_python_3.rst:308 msgid "The third-party Python `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 `_ ライブラリーは、プロジェクトが Python 2 および Python 3 の両方で実行するコードを作成するのに役立ちます。Ansible には、module_utils にライブラリーのバージョンが含まれ、他のモジュールがリモートシステムにインストールされなくても使用可能となるようになっています。これを使用して、以下のようにインポートしてください。" #: ../../rst/dev_guide/developing_python_3.rst:318 msgid "Ansible can also use a system copy of six" msgstr "Ansible は、six のシステムコピーを使用することもできます。" #: ../../rst/dev_guide/developing_python_3.rst:320 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 がバンドルしているものよりも後のバージョンのものであれば、6 のシステムコピーを使用します。" #: ../../rst/dev_guide/developing_python_3.rst:324 msgid "Handle exceptions with ``as``" msgstr "``as`` で例外を処理します。" #: ../../rst/dev_guide/developing_python_3.rst:326 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:336 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:347 msgid "Update octal numbers" msgstr "8 進数の更新" #: ../../rst/dev_guide/developing_python_3.rst:349 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:353 msgid "String formatting for controller code" msgstr "コントローラーコードの文字列形式" #: ../../rst/dev_guide/developing_python_3.rst:356 msgid "Use ``str.format()`` for Python 2.6 compatibility" msgstr "Python 2.6 の互換性のために ``str.format()`` を使用します。" #: ../../rst/dev_guide/developing_python_3.rst:358 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:370 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:376 msgid "Python documentation on `format strings `_" msgstr "`フォーマットの文字列 `_ に関する Python ドキュメント" #: ../../rst/dev_guide/developing_python_3.rst:379 msgid "Use percent format with byte strings" msgstr "バイト文字列でのパーセント書式の使用" #: ../../rst/dev_guide/developing_python_3.rst:381 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:388 msgid "Percent formatting added in Python 3.5" msgstr "Python 3.5 に追加されたパーセント書式" #: ../../rst/dev_guide/developing_python_3.rst:390 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.5 に、バイト文字列のパーセント書式が追加されました。Python 3.5 は最小バージョンであるため、これは問題ではありません。ただし、Python 3.4 以前のバージョンで Ansible のコードをテストしている場合は、ここでのバイト文字列の書式設定が適切に処理されないことがあります。その場合は、Python 3.5 にアップグレードしてテストしてください。" #: ../../rst/dev_guide/developing_python_3.rst:397 msgid "Python documentation on `percent formatting `_" msgstr "`パーセンテージフォーマット `_ に関するドキュメント" #: ../../rst/dev_guide/developing_python_3.rst:402 msgid "Testing modules on Python 3" msgstr "Python 3 でのモジュールのテスト" #: ../../rst/dev_guide/developing_python_3.rst:404 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 ` pages for more information." msgstr "Ansible モジュールは、その他のプロジェクトの通常のコードよりも Python 3 をサポートするようにコーディングするのが若干難しくなります。多くのモックは、Ansible モジュールのユニットテストに入る必要があるため、変更によってすべてが修正されたことをテストするか、後のコミットが Python 3 をサポートしないようにする方が困難になります。詳細は、:ref:`テスト ` ページを参照してください。" #: ../../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:23 msgid "However, you also need to add a remote which points to the upstream repository::" msgstr "ただし、アップストリームのリポジトリーを参照するリモートを追加する必要もあります。" #: ../../rst/dev_guide/developing_rebasing.rst:27 msgid "Which should leave you with the following remotes::" msgstr "次のリモートを残す必要があります。" #: ../../rst/dev_guide/developing_rebasing.rst:35 msgid "Checking the status of your branch should show your fork is up-to-date with the ``origin`` remote::" msgstr "ブランチのステータスを確認すると、``作成元`` のリモートのフォークが最新の状態であることを理解できます。" #: ../../rst/dev_guide/developing_rebasing.rst:43 msgid "Rebasing your branch" msgstr "ブランチのリベース" #: ../../rst/dev_guide/developing_rebasing.rst:45 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:49 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:52 msgid "After you rebase, the status of your branch changes::" msgstr "リベース後に、ブランチのステータスが変更になります。" #: ../../rst/dev_guide/developing_rebasing.rst:61 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:64 msgid "Updating your pull request" msgstr "プル要求の更新" #: ../../rst/dev_guide/developing_rebasing.rst:66 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:68 msgid "Since rebasing re-writes git history, you will need to use a force push::" msgstr "git 履歴を再書き込みするため、強制的にプッシュする必要があります。" #: ../../rst/dev_guide/developing_rebasing.rst:72 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:76 msgid "Getting help rebasing" msgstr "ヘルプの再ベース" #: ../../rst/dev_guide/developing_rebasing.rst:78 msgid "For help with rebasing your PR, or other development related questions, join us on our #ansible-devel IRC chat channel on `freenode.net `_." msgstr "PR またはその他の開発関連の質問を再設定する際には、`freenode.net `_ で IRC チャットチャンネル #ansible-devel に参加します。" #: ../../rst/dev_guide/developing_rebasing.rst:82 msgid ":ref:`community_development_process`" msgstr ":ref:`community_development_process`" #: ../../rst/dev_guide/developing_rebasing.rst:83 msgid "Information on roadmaps, opening PRs, Ansibullbot, and more" msgstr "ロードマップ、オープン PRS、Ansibullbot などに関する情報" #: ../../rst/dev_guide/index.rst:5 msgid "Developer Guide" msgstr "開発者ガイド" #: ../../rst/dev_guide/index.rst:9 msgid "**Making Open Source More Inclusive**" msgstr "**多様性を受け入れるオープンソースの強化**" #: ../../rst/dev_guide/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 `_." msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ `_ を参照してください。" #: ../../rst/dev_guide/index.rst:13 msgid "Welcome to the Ansible Developer Guide!" msgstr "Ansible 開発者ガイドにようこそ!" #: ../../rst/dev_guide/index.rst:15 msgid "**Who should use this guide?**" msgstr "**本ガイドの対象者**" #: ../../rst/dev_guide/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/index.rst:19 msgid "Find the task that best describes what you want to do:" msgstr "以下の中から、お客様のニーズに最も適したタスクを選んでください。" #: ../../rst/dev_guide/index.rst:21 msgid "I'm looking for a way to address a use case:" msgstr "ユースケースに対応する方法を探している。" #: ../../rst/dev_guide/index.rst:23 msgid "I want to :ref:`add a custom plugin or module locally `." msgstr ":ref:`カスタムプラグインまたはモジュールをローカルに追加 ` したいです。" #: ../../rst/dev_guide/index.rst:24 msgid "I want to figure out if :ref:`developing a module is the right approach ` for my use case." msgstr "選択したユースケースでは、:ref:`モジュールの開発が適切なアプローチである ` かどうかを確認したいです。" #: ../../rst/dev_guide/index.rst:25 msgid "I want to :ref:`develop a collection `." msgstr ":ref:`コレクションを開発 ` したいです。" #: ../../rst/dev_guide/index.rst:26 msgid "I want to :ref:`contribute to an Ansible-maintained collection `." msgstr ":ref:`Ansible が管理するコレクションに貢献 ` したいです。" #: ../../rst/dev_guide/index.rst:27 msgid "I want to :ref:`contribute to a community-maintained collection `." msgstr ":ref:`コミュニティーが管理するコレクションに貢献 ` したいです。" #: ../../rst/dev_guide/index.rst:28 msgid "I want to :ref:`migrate a role to a collection `." msgstr ":ref:`ロールをコレクションに移行 ` したいです。" #: ../../rst/dev_guide/index.rst:30 msgid "I've read the info above, and I'm sure I want to develop a module:" msgstr "上記の情報を読んで、モジュールを開発したい。" #: ../../rst/dev_guide/index.rst:32 msgid "What do I need to know before I start coding?" msgstr "コーディングを始める前に何を知っておくべきか。" #: ../../rst/dev_guide/index.rst:33 msgid "I want to :ref:`set up my Python development environment `." msgstr ":ref:`Python 開発環境をセットアップ ` したいです。" #: ../../rst/dev_guide/index.rst:34 msgid "I want to :ref:`get started writing a module `." msgstr ":ref:`モジュールの記述を開始 ` したいです。" #: ../../rst/dev_guide/index.rst:40 msgid "I want to write a specific kind of module:" msgstr "特定のモジュールを作成したい。" #: ../../rst/dev_guide/index.rst:36 msgid "a :ref:`network module `" msgstr ":ref:`ネットワークモジュール `" #: ../../rst/dev_guide/index.rst:37 msgid "a :ref:`Windows module `." msgstr ":ref:`Windows モジュール `" #: ../../rst/dev_guide/index.rst:38 msgid "an :ref:`Amazon module `." msgstr ":ref:`Amazon モジュール `" #: ../../rst/dev_guide/index.rst:39 msgid "an :ref:`OpenStack module `." msgstr ":ref:`OpenStack モジュール `" #: ../../rst/dev_guide/index.rst:40 msgid "an :ref:`oVirt/RHV module `." msgstr ":ref:`oVirt/RHV モジュール `" #: ../../rst/dev_guide/index.rst:41 msgid "a :ref:`VMware module `." msgstr ":ref:`VMware モジュール `" #: ../../rst/dev_guide/index.rst:42 msgid "I want to :ref:`write a series of related modules ` that integrate Ansible with a new product (for example, a database, cloud provider, network platform, and so on)." msgstr "Ansible を新規製品 (例: データベース、クラウドプロバイダー、ネットワークプラットフォーム) と統合する :ref:`一連の関連モジュールを記述 ` したいです。" #: ../../rst/dev_guide/index.rst:44 msgid "I want to refine my code:" msgstr "コードを改良したい。" #: ../../rst/dev_guide/index.rst:46 msgid "I want to :ref:`debug my module code `." msgstr ":ref:`モジュールコードをデバッグ ` したいです。" #: ../../rst/dev_guide/index.rst:47 msgid "I want to :ref:`add tests `." msgstr ":ref:`テストを追加 ` したいです。" #: ../../rst/dev_guide/index.rst:48 msgid "I want to :ref:`document my module `." msgstr ":ref:`モジュールをドキュメント化 ` したいです。" #: ../../rst/dev_guide/index.rst:49 msgid "I want to :ref:`document my set of modules for a network platform `." msgstr ":ref:`ネットワークプラットフォームのモジュールセットを文書化 ` したいです。" #: ../../rst/dev_guide/index.rst:50 msgid "I want to follow :ref:`conventions and tips for clean, usable module code `." msgstr ":ref:`クリーンで使いやすいモジュールコードのための規則とヒント ` を適用したいです。" #: ../../rst/dev_guide/index.rst:51 msgid "I want to :ref:`make sure my code runs on Python 2 and Python 3 `." msgstr ":ref:`作成したコードが Python 2 および Python 3 で実行する ` ようにしたいです。" #: ../../rst/dev_guide/index.rst:53 msgid "I want to work on other development projects:" msgstr "他の開発プロジェクトで作業したい。" #: ../../rst/dev_guide/index.rst:55 msgid "I want to :ref:`write a plugin `." msgstr ":ref:`プラグインを記述 ` したいです。" #: ../../rst/dev_guide/index.rst:56 msgid "I want to :ref:`connect Ansible to a new source of inventory `." msgstr ":ref:`Ansible を新しいインベントリーソースに接続 ` したいです。" #: ../../rst/dev_guide/index.rst:57 msgid "I want to :ref:`deprecate an outdated module `." msgstr ":ref:`古いモジュールを非推奨 ` にしたいです。" #: ../../rst/dev_guide/index.rst:59 msgid "I want to contribute back to the Ansible project:" msgstr "Ansible プロジェクトに貢献したい。" #: ../../rst/dev_guide/index.rst:61 msgid "I want to :ref:`understand how to contribute to Ansible `." msgstr ":ref:`Ansible への貢献方法を理解 ` したいです。" #: ../../rst/dev_guide/index.rst:62 msgid "I want to :ref:`contribute my module or plugin `." msgstr ":ref:`モジュールまたはプラグインに貢献 ` したいです。" #: ../../rst/dev_guide/index.rst:63 msgid "I want to :ref:`understand the license agreement ` for contributions to Ansible." msgstr "Ansible に参加するための :ref:`使用許諾契約を理解 ` したいです。" #: ../../rst/dev_guide/index.rst:65 msgid "If you prefer to read the entire guide, here's a list of the pages in order." msgstr "本ガイドをすべて読む場合は、以下に示す順番でページを表示してください。" #: ../../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 `_." msgstr "コレクションを Galaxy にインポートする場合は、`Galaxy 名前空間 `_ が必要です。" #: ../../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 ` have the following directory structure:" msgstr ":ref:`Standalone 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) を使用してロールおよびプラグインを使用する必要があります。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 "プラグインが含まれないスタンドアロンロールから collection ロールに移行するには、以下を行います。" #: ../../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:123 msgid "Create a collection. If you want to import this collection to Ansible Galaxy, you need a `Galaxy namespace `_." msgstr "コレクションを作成します。このコレクションを Ansible Galaxy にインポートする場合は、`Galaxy 名前空間 `_ が必要です。" #: ../../rst/dev_guide/migrating_roles.rst:100 #: ../../rst/dev_guide/migrating_roles.rst:129 msgid "This creates the collection directory structure." msgstr "これにより、コレクションディレクトリー構造が作成されます。" #: ../../rst/dev_guide/migrating_roles.rst:102 #: ../../rst/dev_guide/migrating_roles.rst:131 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:147 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:149 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:117 msgid "Migrating a role with plugins to a collection" msgstr "プラグインを持つロールをコレクションに移行する" #: ../../rst/dev_guide/migrating_roles.rst:119 msgid "To migrate from a standalone role that has plugins to a collection role:" msgstr "プラグインが含まれないスタンドアロンロールから collection ロールに移行するには、以下を行います。" #: ../../rst/dev_guide/migrating_roles.rst:121 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:139 msgid "Move any modules to the :file:`plugins/modules/` directory." msgstr "モジュールを :file:`plugins/modules/` ディレクトリーに移動します。" #: ../../rst/dev_guide/migrating_roles.rst:145 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:151 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:164 msgid "You can alternately use the ``collections`` keyword to simplify this:" msgstr "別の方法では、``collections`` キーワードを使用してこれを単純化することもできます。" #: ../../rst/dev_guide/migrating_roles.rst:182 msgid "Migrating other role plugins to a collection" msgstr "他のロールプラグインからコレクションへの移行" #: ../../rst/dev_guide/migrating_roles.rst:184 msgid "To migrate other role plugins to a collection:" msgstr "その他のロールプラグインをコレクションに移行するには、以下を実行します。" #: ../../rst/dev_guide/migrating_roles.rst:187 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:193 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:195 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:198 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:200 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:202 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:208 msgid "Updating ``module_utils``" msgstr " ``module_utils`` の更新" #: ../../rst/dev_guide/migrating_roles.rst:210 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 ` for more details." msgstr "カスタムモジュールのいずれかがカスタムモジュールユーティリティーを使用している場合は、コレクションに移行すると、トップレベルの ``ansible.module_utils`` Python 名前空間でモジュールユーティリティーを扱うことができません。Ansible は、コレクションのコンテンツを Ansible 内部の Python 名前空間にマージしません。カスタムコンテンツをコレクションに移行する際は、カスタムモジュールユーティリティーを参照している Python の import 文を更新してください。詳細は、「:ref:`コレクションの module_utils `」を参照してください。" #: ../../rst/dev_guide/migrating_roles.rst:212 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:220 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:222 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:224 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:250 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:272 msgid "Importing from __init__.py" msgstr "__init__.py からのインポート" #: ../../rst/dev_guide/migrating_roles.rst:274 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`` という名前のコレクションの中にあるコールバックプラグインの一部である :file:`__init__.py` というファイルです。" #: ../../rst/dev_guide/migrating_roles.rst:282 msgid "Example: Migrating a standalone role with plugins to a collection" msgstr "例: プラグインを持つスタンドアロンロールをコレクションに移行" #: ../../rst/dev_guide/migrating_roles.rst:284 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:299 msgid "Create a new collection, for example, ``acme.webserver``:" msgstr "新規コレクションを作成します (``acme.webserver`` など)。" #: ../../rst/dev_guide/migrating_roles.rst:312 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:319 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:327 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:329 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:333 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 ` 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:`コレクションのキーワード ` を追加することができます。通常、ロールは抽象化されたレイヤーであり、ユーザーはロールのコンポーネントを独立して使用することはありません。" #: ../../rst/dev_guide/migrating_roles.rst:337 msgid "Example: Supporting standalone roles and migrated collection roles in a downstream RPM" msgstr "例: ダウンストリーム RPM でのスタンドアロンロールと移行されたコレクションロールのサポート" #: ../../rst/dev_guide/migrating_roles.rst:339 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 `_ and provide existing backwards compatibility with the downstream RPM." msgstr "スタンドアロンのロールは、対応するコレクションロールと共存することができます (例: 製品のサポートライフサイクルの一部として)。これは移行期間のみ行うべきですが、これら 2 つは RPM などのパッケージでダウンストリームに存在することができます。たとえば、RHEL のシステムロールは `example of a RHEL system roles collection `_ と共存し、ダウンストリーム RPM との既存の後方互換性を提供することができます。" #: ../../rst/dev_guide/migrating_roles.rst:341 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:343 msgid "To deliver a role as both a standalone role and a collection role:" msgstr "スタンドアロンロールとコレクションロールの両方としてロールを提供するには、以下を実行します。" #: ../../rst/dev_guide/migrating_roles.rst:345 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:346 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:348 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:350 msgid "The following is an example RPM spec file that accomplishes this using this example content:" msgstr "以下は、このサンプルの内容を使用してこれを実現する RPM 仕様ファイルの例です。" #: ../../rst/dev_guide/module_lifecycle.rst:5 msgid "The lifecycle of an Ansible module" msgstr "Ansible モジュールのライフサイクル" #: ../../rst/dev_guide/module_lifecycle.rst:7 msgid "Modules in the main Ansible repo have a defined life cycle, from first introduction to final removal. The module life cycle is tied to the `Ansible release cycle `. A module may move through these four states:" msgstr "メインの Ansible リポジトリーのモジュールには、最初の導入から最後の削除までライフサイクルが定義されます。モジュールのライフサイクルは、`Ansible リリースサイクル ` に紐づけられ、モジュールは、次の 4 つの状態を通過する可能性があります。" #: ../../rst/dev_guide/module_lifecycle.rst:10 msgid "When a module 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 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 "モジュールが成熟すると、ドキュメントの「プレビュー」マークが削除されます。これらのモジュールに対する後方互換性はサポートします (が保証はしません)。つまり、パラメーターは安定した方法で維持する必要があります。" #: ../../rst/dev_guide/module_lifecycle.rst:14 msgid "If a module's target API changes radically, or if someone creates a better implementation of its functionality, we may mark it deprecated. Modules that are deprecated are still available but they are reaching the end of their life cycle. We retain deprecated modules 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 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 ファイルは、ユーザーが代替モジュールを見つけるのに役立ちます。" #: ../../rst/dev_guide/module_lifecycle.rst:21 msgid "Deprecating modules" msgstr "モジュールの非推奨化" #: ../../rst/dev_guide/module_lifecycle.rst:23 msgid "To deprecate a module, you must:" msgstr "モジュールの使用を終了するには、以下を行う必要があります。" #: ../../rst/dev_guide/module_lifecycle.rst:25 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:26 msgid "Mention the deprecation in the relevant ``CHANGELOG``." msgstr "関連する ``CHANGELOG`` の非推奨に言及してください。" #: ../../rst/dev_guide/module_lifecycle.rst:27 msgid "Reference the deprecation in the relevant ``porting_guide_x.y.rst``." msgstr "関連する ``porting_guide_x.y.rst`` で非推奨化を参照します。" #: ../../rst/dev_guide/module_lifecycle.rst:28 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:30 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:31 msgid "(Added in Ansible 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 2.10 に追加されます)。モジュールの削除時に ISO 8601 形式の日付。通常は、モジュールが非推奨になってから 2 年間となります。このモジュールでは、:removed_in: と相互排他的になります。" #: ../../rst/dev_guide/module_lifecycle.rst msgid "why" msgstr "理由" #: ../../rst/dev_guide/module_lifecycle.rst:32 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:33 msgid "Inform users they should do instead, for example, ``Use M(whatmoduletouseinstead) instead.``." msgstr "ユーザーが代わりにすべきことを通知します (例: ``Use M(whatmoduletouseinstead) instead.``)。" #: ../../rst/dev_guide/module_lifecycle.rst:35 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`` では、非推奨となったマークにこのファイル内の別のエントリーがすぐに必要になることがあります。" #: ../../rst/dev_guide/module_lifecycle.rst:37 msgid "For an example of documenting deprecation, see this `PR that deprecates multiple modules `_. Some of the elements in the PR might now be out of date." msgstr "ドキュメントの非推奨の例は、「`複数のモジュールを非推奨にする PR `_」を参照してください。PR の一部の要素が最新でない可能性があります。" #: ../../rst/dev_guide/module_lifecycle.rst:41 msgid "Changing a module name" msgstr "モジュール名の変更" #: ../../rst/dev_guide/module_lifecycle.rst:43 msgid "You can also rename a module and keep an 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/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 `, though you should first consider :ref:`whether you should `. 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:`独自のモジュールを記述 ` ができますが、最初に :ref:`記述すべきかどうか ` を検討する必要があります。通常、任意のターミナルプログラム、テキストエディター、およびおそらくバージョン管理システムを使用して、コンテンツへの変更を追跡します。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 ` as well. Module utilities may only be written in Python or in PowerShell." msgstr "複数のモジュールが同じコードを使用する場合は、Ansible がこの機能をモジュールユーティリティーとして保存し、重複とメンテナンスを最小限に抑えます。たとえば、URL を解析するコードは次のとおりです (``lib/ansible/module_utils/url.py``)。:ref:`独自のモジュールユーティリティーを記述 ` をすることもできます。モジュールユーティリティーは、Python または PowerShell でのみ記述できます。" #: ../../rst/dev_guide/overview_architecture.rst:30 msgid "Plugins" msgstr "プラグイン" #: ../../rst/dev_guide/overview_architecture.rst:32 msgid ":ref:`Plugins ` 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 `. For example, you can write an :ref:`inventory plugin ` to connect to any datasource that returns JSON. Plugins must be written in Python." msgstr ":ref:`Plugins ` は、Ansible のコア機能を拡張するものです。モジュールがターゲットシステム上で別のプロセス (通常はリモートシステム上) で実行されるのに対し、プラグインは、``/usr/bin/ansible`` プロセス内のコントロールノードで実行されます。プラグインは、データの変換、出力のロギング、インベントリーへの接続など、Ansible のコア機能のオプションや拡張機能を提供します。Ansible には便利なプラグインが多数同梱されており、簡単に :ref:`自作 ` できます。たとえば、JSON を返すあらゆるデータソースに接続するための :ref:`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:54 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:56 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:59 msgid "Playbooks" msgstr "Playbook" #: ../../rst/dev_guide/overview_architecture.rst:61 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:63 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:65 msgid "Here's what a simple playbook looks like::" msgstr "以下は単純な Playbook の例です。" #: ../../rst/dev_guide/overview_architecture.rst:82 msgid "The Ansible search path" msgstr "Ansible 検索パス" #: ../../rst/dev_guide/overview_architecture.rst:84 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 が特定の Playbook の実行で検出して使用するこれらのファイルが決まります。" #: ../../rst/dev_guide/overview_architecture.rst:87 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:93 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:101 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:111 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:120 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:131 msgid "Sample environment variables:" msgstr "以下は、環境変数の例となります。" #: ../../rst/dev_guide/overview_architecture.rst:140 msgid "The standard directories that ship as part of the Ansible distribution." msgstr "Ansible ディストリビューションに同梱される標準ディレクトリー。" #: ../../rst/dev_guide/overview_architecture.rst:144 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:149 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 "The Ansible AWS collection (on `Galaxy `_, source code `repository `_) is maintained by the Ansible AWS Working Group. For further information see the `AWS working group community page `_. 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 `_ では、ソースコード `レポジトリー `_) は、Ansible AWS のワーキンググループ維持されます。詳細は `AWS ワーキンググループのコミュニティーページ `_ を参照してください。AWS モジュールを Ansible に提供することを計画している場合は、特に同様のモジュールがすでに開発中である可能性があるため、ワーキンググループに連絡することから始めることを推奨します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:13 msgid "Maintaining existing modules" msgstr "既存のモジュールのメンテナンス" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:16 msgid "Fixing bugs" msgstr "バグの修正" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:18 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 を使用するように移植する必要があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:22 msgid "Adding new features" msgstr "新しい機能の追加" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:24 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 のバージョンを示すメッセージが表示されます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:29 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`` モジュールからです。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:41 msgid "Migrating to boto3" msgstr "boto3 への移行" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:43 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 依存関係を削除したいと考えています。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:47 msgid "Porting code to AnsibleAWSModule" msgstr "AnsibleAWSModule へのコードの移植" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:49 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`` に移植するには、以下を変更します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:57 msgid "to:" msgstr "以下のように変更します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:65 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 のメソッドを継承しませんが、最も便利なメソッドが含まれています。問題を発見した場合は、バグレポートを提出してください。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:69 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 引数仕様も追加します。事前ポートモジュールでは、以下で指定された一般的な引数が表示されるはずです。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:84 msgid "These can be replaced with:" msgstr "これは、次のものと置き換えることができます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:97 msgid "Creating new AWS modules" msgstr "新規 AWS モジュールの作成" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:100 msgid "Use boto3 and AnsibleAWSModule" msgstr "boto3 および AnsibleAWSModule の使用" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:102 msgid "All new AWS modules must use boto3 and ``AnsibleAWSModule``." msgstr "すべての新規 AWS モジュールは boto3 および ``AnsibleAWSModule`` を使用する必要があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:104 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`` をベースとして使えない場合は、理由を文書化し、このルールの例外を要求する必要があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:109 msgid "Naming your module" msgstr "モジュールの名前付け" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:111 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 など) のよく知られた省略形である場合は問題ありませんが、新しい名前を個別に作成しないでください。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:116 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`` となります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:119 msgid "Importing botocore and boto3" msgstr "botocore および boto3 のインポート" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:121 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`` を確認する必要はありません。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:135 msgid "or:" msgstr "または" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:152 msgid "Supporting Module Defaults" msgstr "モジュールのデフォルトのサポート" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:154 msgid "The existing AWS modules support using :ref:`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 ` を使用したサポートです。新しいモジュールに同じモジュールを行うには、``lib/ansible/config/module_defaults.yml`` でエントリーを追加します。これらのエントリーは以下の形式になります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:164 msgid "Connecting to AWS" msgstr "AWS への接続" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:166 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 プロファイルなど、より難解な接続オプションのいくつかを処理します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:169 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 に接続する必要があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:172 msgid "These helpers also for missing profiles or a region not set when it needs to be, so you don't have to." msgstr "これらのヘルパーは、欠落しているプロファイルや、必要なときに設定されていない領域にも使用できるため、必須ではありません。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:174 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`` の例外をキャッチする必要があります。「例外処理」を参照してください。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:184 msgid "or for the higher level ec2 resource:" msgstr "また、より高いレベルの ec2 リソースの場合は、次のようになります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:191 msgid "An example of the older style connection used for modules based on AnsibleModule rather than AnsibleAWSModule:" msgstr "AnsibleAWSModule ではなく AnsibleModule に基づくモジュールに使用される旧式の接続例は次のとおりです。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:205 msgid "Common Documentation Fragments for Connection Parameters" msgstr "接続パラメーターに関する断片化された汎用ドキュメント" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:207 msgid "There are two :ref:`common documentation fragments ` that should be included into almost all AWS modules:" msgstr "ほとんどすべての AWS モジュールに含まれる :ref:`断片化された汎用ドキュメント ` は 2 つあります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:210 msgid "``aws`` - contains the common boto connection parameters" msgstr "``aws`` - 共通の boto 接続パラメーターが含まれます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:211 msgid "``ec2`` - contains the common region parameter required for many AWS modules" msgstr "``ec2`` - 数多くの AWS モジュールに必要な共通の region パラメーターが含まれます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:213 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 "一貫性を確保し、より難解な接続オプションを文書化するには、このようなプロパティーを再文書化するのではなく、このような断片化されたドキュメントを使用する必要があります。たとえば、以下のようになります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:228 msgid "Handling exceptions" msgstr "例外の処理" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:230 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 呼び出しをラップする必要があります。例外がスローされると、処理の可能性が多数あります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:233 msgid "Catch the general ``ClientError`` or look for a specific error code with" msgstr "汎用的な ``ClientError`` を取得するか、次のような特定のエラーコードを探します" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:234 msgid "``is_boto3_error_code``." msgstr "``is_boto3_error_code``." #: ../../rst/dev_guide/platforms/aws_guidelines.rst:235 msgid "Use ``aws_module.fail_json_aws()`` to report the module failure in a standard way" msgstr "``aws_module.fail_json_aws()`` を使用して、標準的な方法でモジュール障害を報告します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:236 msgid "Retry using AWSRetry" msgstr "AWSRetry を使用して再試行します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:237 msgid "Use ``fail_json()`` to report the failure without using ``ansible.module_utils.aws.core``" msgstr "``fail_json()`` を使用して、``ansible.module_utils.aws.core`` を使用せずに障害を報告します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:238 msgid "Do something custom in the case where you know how to handle the exception" msgstr "例外の処理方法が分かっている場合は、何らかのカスタマイズ作業を行います。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:240 msgid "For more information on botocore exception handling see the `botocore error documentation `_." msgstr "botocore 例外処理の詳細は、`botocore エラードキュメント `_ を参照してください。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:243 msgid "Using is_boto3_error_code" msgstr "is_boto3_error_code の使用" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:245 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`` エラーコードをここに検出し、その他のエラーでプログラム内の別の場所を処理する際に発生します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:259 msgid "Using fail_json_aws()" msgstr "fail_json_aws() の使用" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:261 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 の冗長モードで使用するためにトレースバックと共にエラーを報告します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:265 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 を使用するようにモジュールを移行することが推奨されます (これを行うために必要な変更はほとんどありません)。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:286 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 以外の例外が予想される場合は、すべてが期待どおりに機能するかどうかをテストする必要があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:289 #: ../../rst/dev_guide/platforms/aws_guidelines.rst:334 msgid "If you need to perform an action based on the error boto3 returned, use the error code." msgstr "返された boto3 エラーに基づいてアクションを実行する必要がある場合は、このエラーコードを使用します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:306 msgid "using fail_json() and avoiding ansible.module_utils.aws.core" msgstr "fail_json() and avoiding ansible.module_utils.aws.core の使用" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:308 msgid "Boto3 provides lots of useful information when an exception is thrown so pass this to the user along with the message." msgstr "Boto3 は、例外が発生したときに多くの有用な情報を提供するため、メッセージと共にこれをユーザーに渡します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:331 msgid "Note: we use `str(e)` rather than `e.message` as the latter doesn't work with python3" msgstr "注記: 後者は python3 では機能しないため、`e.message` の代わりに `str(e)` を使用します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:354 msgid "API throttling (rate limiting) and pagination" msgstr "API スロットリング (レート制限) とページネーション" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:356 msgid "For methods that return a lot of results, boto3 often provides `paginators `_. 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 `_ を提供します。呼び出しているメソッドに ``NextToken`` パラメーターまたは ``Marker`` パラメーターがある場合は、Paginator が存在するかどうかを確認する必要があります (各 boto3 サービスに paginator がある場合は、参照ページ上部に Paginator へのリンクがあります)。paginator を使用するには、paginator オブジェクトを取得し、適切な引数を指定して ``paginator.paginate`` を呼び出してから、``build_full_result`` を呼び出します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:363 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 が正しく機能するためにスロットリング例外を取得する必要があるため)、バックオフ関数を提供してから、バックオフ関数の周りに例外処理を配置する必要があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:369 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 `_ for more details." msgstr "``exponential_backoff`` または ``jittered_backoff`` ストラテジーを使用できます。詳細は、クラウド ``module_utils`` ()/lib/ansible/module_utils/cloud.py) および `AWS アーキテクチャーのブログ `_ を参照してください。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:373 msgid "The combination of these two approaches is then:" msgstr "これら 2 つのアプローチの組み合わせは次のとおりです。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:390 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`` はこれが出力されなくなるまで再試行する合図としてこれを受け取ります (これは、リソースを作成するときに、リソースが存在するまで再試行できるようにするためです)。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:394 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`` で承認の失敗またはパラメーター検証エラーを処理するには、以下が必要になります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:420 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`` (クライアントからの呼び出し) によって返されたクライアントをラップできるようになりました。クライアントに再試行を追加するには、クライアントを作成します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:428 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` 引数を使用して呼び出し時に渡されたデコレーターを使用して行うことができます。デフォルトでは、再試行は使用されません。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:443 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 "呼び出しは指定された回数だけ再試行されるため、呼び出し元の関数をバックオフデコレーターでラップする必要はありません。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:446 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 ` module for example." msgstr "また、モジュールパラメーターを使用して、``AWSRetry.jittered_backoff`` API が使用する ``retries`` パラメーター、``delay`` パラメーター、および ``max_delay`` パラメーターのカスタマイズを使用することもできます。たとえば、`cloudformation ` モジュールを参照してください。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:451 msgid "To make all Amazon modules uniform, prefix the module param with ``backoff_``, so ``retries`` becomes ``backoff_retries``" msgstr "すべての Amazon モジュールを均一にするには、モジュールパラメーターの前に ``backoff_`` を付けます。これにより、``retries`` は ``backoff_retries`` になります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:451 msgid "and likewise with ``backoff_delay`` and ``backoff_max_delay``." msgstr "``backoff_delay`` と ``backoff_max_delay`` も同様です。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:454 msgid "Returning Values" msgstr "戻り値" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:456 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 を使用して呼び出しを行うと、モジュールで返す必要がある便利な情報を入手できます。また、呼び出し自体に関連する情報や応答メタデータもあります。これをユーザーに返すことは問題ありませんが、ユーザーはそれが役立つと思うかもしれません。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:460 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 に変換できます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:464 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」に変更しないでください。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:476 msgid "Dealing with IAM JSON policy" msgstr "IAM JSON ポリシーの処理" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:478 msgid "If your module accepts IAM JSON policies then set the type to 'json' in the module spec. For example:" msgstr "モジュールが IAM JSON ポリシーを受け入れる場合は、モジュール仕様でタイプを「json」に設定します。たとえば、以下のようになります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:489 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` ヘルパー関数を使用します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:492 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 を返します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:516 msgid "Dealing with tags" msgstr "タグの処理" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:518 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 の呼び出しがあります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:521 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 モジュールでは一般的な方法です。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:524 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 タスクで指定されていない場合に削除されることを示しています。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:527 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 つのディクショナリーを比較し、設定するタグと削除するタグを返すことができます。詳細については、以下のヘルパー関数のセクションを参照してください。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:532 msgid "Helper functions" msgstr "helper 関数" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:534 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 の接続関数に加えて、以下に説明するいくつかの便利な関数があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:538 msgid "camel_dict_to_snake_dict" msgstr "camel_dict_to_snake_dict" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:540 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 に変換します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:543 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`` ディクショナリーに役に立ちます。この子キーは大文字と小文字を区別して保持する必要があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:547 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`` に変換され直されます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:552 msgid "snake_dict_to_camel_dict" msgstr "snake_dict_to_camel_dict" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:554 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 への変換に使用できます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:559 msgid "ansible_dict_to_boto3_filter_list" msgstr "ansible_dict_to_boto3_filter_list" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:561 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` モジュールに役立ちます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:565 msgid "boto_exception" msgstr "boto_exception" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:567 msgid "Pass an exception returned from boto or boto3, and this function will consistently get the message from the exception." msgstr "boto または boto3 から返された例外を渡します。この関数は、例外からメッセージを一貫して取得します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:569 msgid "Deprecated: use `AnsibleAWSModule`'s `fail_json_aws` instead." msgstr "非推奨: 代わりに `AnsibleAWSModule` の `fail_json_aws` を使用してください。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:573 msgid "boto3_tag_list_to_ansible_dict" msgstr "boto3_tag_list_to_ansible_dict" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:575 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」を渡すことができます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:580 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 値はタグの値です。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:584 msgid "ansible_dict_to_boto3_tag_list" msgstr "ansible_dict_to_boto3_tag_list" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:586 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」が適していないときに使用されるキー名を再度上書きすることもできます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:590 msgid "get_ec2_security_group_ids_from_names" msgstr "get_ec2_security_group_ids_from_names" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:592 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 も渡す必要があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:597 msgid "compare_policies" msgstr "compare_policies" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:599 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 を返します。これにより、ディクショナリーが再帰的にソートされ、比較前にハッシュ可能になります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:602 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 "この方法は、順序を変更しても不要な変更が発生しないように、ポリシーを比較するときに必ず使用する必要があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:606 msgid "compare_aws_tags" msgstr "compare_aws_tags" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:608 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 の場合は、既存のタグが変更されません。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:612 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}]` の形式にする必要があるなど)。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:619 msgid "Integration Tests for AWS Modules" msgstr "AWS モジュールの統合テスト" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:621 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 呼び出しに対応し、文書化された戻り値がモジュールの結果に存在するようにする必要があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:625 msgid "For general information on running the integration tests see the :ref:`Integration Tests page of the Module Development Guide `, especially the section on configuration for cloud tests." msgstr "統合テストの実行に関する一般的な情報は、:ref:`モジュール開発ガイドの統合テストページ ` ページ (特に、クラウドテスト設定のセクション) を参照してください。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:628 msgid "The integration tests for your module should be added in `test/integration/targets/MODULE_NAME`." msgstr "モジュールの統合テストは、`test/integration/targets/MODULE_NAME` に追加する必要があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:630 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 認証情報を利用できるようにしていることを示します。次に、テストをテストグループに入れて、継続的インテグレーションビルドで実行します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:635 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 `_." msgstr "新規モジュールのテストは、既存の AWS テストと同じグループに追加する必要があります。一般に、`aws_s3 テストエイリアスファイル `_ のような既存のエイリアスファイルをコピーするだけです。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:639 msgid "AWS Credentials for Integration Tests" msgstr "統合テストの AWS 認証情報" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:641 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 認証情報を使用したテストの実行を処理します。この認証情報は、次の変数で、テストに利用できます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:644 msgid "`aws_region`" msgstr "`aws_region`" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:645 msgid "`aws_access_key`" msgstr "`aws_access_key`" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:646 msgid "`aws_secret_key`" msgstr "`aws_secret_key`" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:647 msgid "`security_token`" msgstr "`security_token`" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:649 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 `. For example:" msgstr "したがって、テストで AWS モジュールを呼び出す場合はすべて、これらのパラメーターを設定する必要があります。呼び出しごとにこれらが重複しないようにするには、:ref:`module_defaults ` を使用することが推奨されます。以下に例を示します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:673 msgid "AWS Permissions for Integration Tests" msgstr "統合テスト用の AWS パーミッション" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:675 msgid "As explained in the :ref:`Integration Test guide ` there are defined IAM policies in `mattclay/aws-terminator `_ that contain the necessary permissions to run the AWS integration test." msgstr ":ref:`Integration Test guide ` で説明されているように、AWS 統合テストを実行するために必要な権限が含まれる `mattclay/aws-terminator `_ で定義された IAM ポリシーがあります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:679 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 `_ 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 `_ to add them." msgstr "モジュールが新しいサービスとやり取りする場合、または別の方法で新しいパーミッションが必要な場合は、プル要求を送信すると、テストは失敗します。`Ansibullbot `_ は、PR に修正が必要なタグを付けます。継続的インテグレーションビルドで使用されるロールに追加のパーミッションを自動的に付与することはありません。それを追加するには、`mattclay/aws-terminator `_ に対してプル要求を発行する必要があります、それらを追加します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:684 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` タグを使用してコメントを追加して、権限がないことが原因であることを説明します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:687 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 パーミッションを収集する必要があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:691 msgid "There are two ways to figure out which IAM permissions you need for your PR to pass:" msgstr "PR に合格するために必要な IAM パーミッションを確認する場合は、以下の 2 つの方法があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:693 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` を使用するモジュールでのみ機能します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:694 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` を使用する場合は、このアプローチを使用する必要があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:696 msgid "To start with the most permissive IAM policy:" msgstr "最も許容度の高い IAM ポリシーを使用するには、以下を実行します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:698 msgid "`Create an IAM policy `_ that allows all actions (set ``Action`` and ``Resource`` to ``*```)." msgstr "すべてのアクションを許可する `IAM ポリシーを作成 `_ します (``Action`` および ``Resource`` を ``*``' に設定)。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:699 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 モジュールを使用する場合は、最も許容度の低いポリシーから開始する必要があります (以下を参照)。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:700 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 "テストで使用するアクションのみを許可するようにポリシーを変更します。可能な場合は、アカウント、地域、プレフィックスを制限してください。ポリシーが更新されるまで数分待ちます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:701 msgid "Run the tests again with a user or role that allows only the new policy." msgstr "新規ポリシーのみを許可するユーザーまたはロールでテストを再実行します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:702 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 "テストに失敗し、トラブルシューティング (以下のヒントを参照) を行い、ポリシーを変更し、テストを再実行し、制限的なポリシーでテストに合格するまでプロセスを繰り返します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:703 #: ../../rst/dev_guide/platforms/aws_guidelines.rst:720 msgid "Open a pull request proposing the minimum required policy to the `CI policies `_." msgstr "`CI policies `_ に対して最低限必要なポリシーを提案するプル要求を開きます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:705 msgid "To start from the least permissive IAM policy:" msgstr "最も許容度の低い IAM ポリシーから開始するには、以下を実行します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:707 msgid "Run the integration tests locally with no IAM permissions." msgstr "IAM パーミッションを持たないローカルの統合テストを実行します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:715 msgid "Examine the error when the tests reach a failure." msgstr "テストが失敗した場合はエラーを確認します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:709 msgid "If the error message indicates the action used in the request, add the action to your policy." msgstr "エラーメッセージがリクエストで使用されるアクションを示す場合は、アクションをポリシーに追加します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:711 msgid "If the error message does not indicate the action used in the request:" msgstr "エラーメッセージがリクエストで使用されるアクションを示していない場合は、以下を行います。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:711 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` に相関します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:712 msgid "Refer to the documentation to identify the action." msgstr "アクションを特定するには、ドキュメントを参照してください。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:713 msgid "If the error message indicates the resource ARN used in the request, limit the action to that resource." msgstr "エラーメッセージが要求で使用されるリソース ARN を示す場合は、アクションをそのリソースに制限します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:715 msgid "If the error message does not indicate the resource ARN used:" msgstr "エラーメッセージに、使用されたリソース ARN が示されない場合は、以下を行います。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:715 msgid "Determine if the action can be restricted to a resource by examining the documentation." msgstr "ドキュメントを参照して、アクションをリソースに制限できるかどうかを判断します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:716 msgid "If the action can be restricted, use the documentation to construct the ARN and add it to the policy." msgstr "アクションが制限されている場合は、ドキュメントを使用して ARN を構築し、ポリシーに追加します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:717 msgid "Add the action or resource that caused the failure to `an IAM policy `_. Wait a few minutes for your policy to update." msgstr "`IAM ポリシー `_ の失敗の原因となったアクションまたはリソースを追加します。ポリシーが更新まで数分待ちます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:718 msgid "Run the tests again with this policy attached to your user or role." msgstr "ユーザーまたはロールにこのポリシーを割り当てテストを再実行します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:719 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 を繰り返します。制限付きポリシーでテストに合格するまで、このプロセスを繰り返します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:723 msgid "Troubleshooting IAM policies" msgstr "IAM ポリシーのトラブルシューティング" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:725 msgid "When you make changes to a policy, wait a few minutes for the policy to update before re-running the tests." msgstr "ポリシーに変更を加えたら、ポリシーが更新されるまで数分待ってからテストを再実行します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:726 msgid "Use the `policy simulator `_ to verify that each action (limited by resource when applicable) in your policy is allowed." msgstr "`ポリシーシミュレーター `_ を使用して、ポリシー内の (該当する場合はリソースによって制限されている) が許可されていることを確認します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:727 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 "特定のリソースにアクションを制限する場合は、リソースを一時的に `*` に置き換えます。ワイルドカードリソースでテストに合格した場合は、ポリシーのリソース定義に問題があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:728 msgid "If the initial troubleshooting above doesn't provide any more insight, AWS may be using additional undisclosed resources and actions." msgstr "上記の最初のトラブルシューティングでより多くの洞察が得られない場合、AWS は追加の未公開のリソースおよびアクションを使用している可能性があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:729 msgid "Examine the AWS FullAccess policy for the service for clues." msgstr "手がかりについては、サービスの AWS FullAccess ポリシーを調べます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:730 msgid "Re-read the AWS documentation, especially the list of `Actions, Resources and Condition Keys `_ for the various AWS services." msgstr "各種の AWS サービスの `Actions, Resources and Condition Keys `_ の一覧など、AWS ドキュメントを再度読みます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:731 msgid "Look at the `cloudonaut `_ documentation as a troubleshooting cross-reference." msgstr "トラブルシューティングの相互参照として `cloudonaut `_ ドキュメントをご覧ください。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:732 msgid "Use a search engine." msgstr "検索エンジンを使用します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:733 msgid "Ask in the Ansible IRC channel #ansible-aws (on freenode IRC)." msgstr "Freenode IRC の Ansible IRC チャンネル #ansible-aws に問い合わせます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:736 msgid "Unsupported Integration tests" msgstr "サポートされないインテグレーションのテスト" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:738 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` のエイリアスファイルに追加する必要があります。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:742 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 組織などのアカウントレベルのセキュリティポリシーを管理します。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:749 msgid "Where one of these reasons apply you should open a pull request proposing the minimum required policy to the `unsupported test policies `_." msgstr "上記の理由の 1 つは、`サポートされないテストポリシー `_ に対して最低限必要なポリシーを提案するプル要求を開きます。" #: ../../rst/dev_guide/platforms/aws_guidelines.rst:752 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 レビューまたはパッチの作成を実行してテストを手動で実行できるようにする必要があります。" #: ../../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 `_, for further information." msgstr "詳細は、`OpenStack ガイドライン `_ を参照してください。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:4 msgid "oVirt Ansible Modules" msgstr "oVirt Ansible モジュール" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:6 msgid "The set of modules for interacting with oVirt/RHV are currently part of the community.general collection (on `Galaxy `_, source code `repository `_). This document serves as developer coding guidelines for creating oVirt/RHV modules." msgstr "oVirt/RHV との対話に使用するモジュールセットは、現在 community.general コレクション (`Galaxy `_ ではソースコード `repository `_) に含まれます。このドキュメントは、oVirt/RHV モジュールを作成するための開発者コーディングのガイドラインとして機能します。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:12 #: ../../rst/dev_guide/testing_validate-modules.rst:93 #: ../../rst/dev_guide/testing_validate-modules.rst:96 #: ../../rst/dev_guide/testing_validate-modules.rst:108 #: ../../rst/dev_guide/testing_validate-modules.rst:135 msgid "Naming" msgstr "命名規則" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:14 msgid "All modules should start with an ``ovirt_`` prefix." msgstr "すべてのモジュールは、``ovirt_`` 接頭辞で開始する必要があります。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:15 msgid "All modules should be named after the resource it manages in singular form." msgstr "すべてのモジュールは、管理するリソースにちなんで単数形で名前を付ける必要があります。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:17 msgid "All modules that gather information should have a ``_info`` suffix." msgstr "情報を収集するすべてのモジュールには、``_info`` 構文があります。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:21 msgid "Interface" msgstr "インターフェース" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:23 msgid "Every module should return the ID of the resource it manages." msgstr "すべてのモジュールは、管理するリソースの ID を返す必要があります。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:24 msgid "Every module should return the dictionary of the resource it manages." msgstr "すべてのモジュールは、管理するリソースのディレクトリーを返す必要があります。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:25 msgid "Never change the name of the parameter, as we guarantee backward compatibility. Use aliases instead." msgstr "後方互換性を保証するため、パラメーターの名前は変更しないでください。代わりにエイリアスを使用してください。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:27 msgid "If a parameter can't achieve idempotency for any reason, please document it." msgstr "パラメーターが何らかの理由で冪等性を実現できない場合は、それを文書化してください。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:31 msgid "Interoperability" msgstr "相互運用性" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:33 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 はサポート対象外です。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:37 msgid "Libraries" msgstr "ライブラリー" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:39 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`` など) にする必要があります。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:42 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 を使用する必要があります。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:44 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`` を使用する必要があります。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:46 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`` ファイルに実装されているため、再利用できます。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:48 msgid "Python SDK version 4 must be used." msgstr "Python SDK バージョン 4 を使用する必要があります。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:51 msgid "New module development" msgstr "新しいモジュール開発" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:53 msgid "Please read :ref:`developing_modules`, first to know what common properties, functions and features every module must have." msgstr "「:ref:`developing_modules`」をお読みください。最初に、すべてのモジュールに必要な共通のプロパティー、関数、および機能を確認します。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:57 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 エンティティー属性のべき等性を実現するには、ヘルパークラスが作成されました。まず、このクラスを拡張し、いくつかのメソッドを上書きする必要があります。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:99 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 に必要なエンティティーを構築します。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:176 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 "モジュールがアクション処理 (例: 仮想マシンの開始) をサポートする必要がある場合は、仮想マシンの状態を正しく処理し、モジュールの動作を文書化する必要があります。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:204 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`` パラメーターを定義して、事前または後続のアクションのタスクを処理することもできます。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:213 msgid "Testing" msgstr "テスト" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:215 msgid "Integration testing is currently done in oVirt's CI system `on Jenkins `__ and `on GitHub `__." msgstr "統合テストは、現在、__ と `GitHub `__ の oVirt's CI システム で行われています。" #: ../../rst/dev_guide/platforms/ovirt_dev_guide.rst:219 msgid "Please consider using these integration tests if you create a new module or add a new feature to an existing module." msgstr "新しいモジュールを作成する場合、または既存のモジュールに新しい機能を追加する場合は、これらの統合テストの使用を検討してください。" #: ../../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 "The Ansible VMware collection (on `Galaxy `_, source code `repository `_) is maintained by the VMware Working Group. For more information see the `team community page `_." msgstr "詳細は、Ansible VMware コレクション (`Galaxy `_ で、ソースコード `repository `_) は VMware ワーキンググループにより維持されます。詳細は `team community page `_ を参照してください。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:13 msgid "Testing with govcsim" msgstr "govcsim を使用したテスト" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:15 msgid "Most of the existing modules are covered by functional tests. The tests are located `here `_." msgstr "既存のモジュールのほとんどは、機能テストで対応しています。テストは、`ここ `_ に置かれます。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:17 msgid "By default, the tests run against a vCenter API simulator called `govcsim `_. ``ansible-test`` will automatically pull a `govcsim container `_ and use it to set-up the test environment." msgstr "デフォルトでは、テストは、`govcsim `_ という名前の vCenter API シミュレーターに対して実行されます。``ansible-test`` は、`govcsim コンテナー `_ を自動的にプルし、これを使用してテスト環境を設定します。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:19 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`` テストを開始するには、以下を行います。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:26 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 機能をすべてサポートしません。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:31 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 言語で書かれています" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:34 msgid "Testing with your own infrastructure" msgstr "独自のインフラストラクチャーでのテスト" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:36 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 環境を対象とすることもできます。この段落では、テストスイートを自分で実行する方法について順を追って説明します。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:39 #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:23 #: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:37 #: ../../rst/dev_guide/testing_running_locally.rst:18 msgid "Requirements" msgstr "要件" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:41 msgid "2 ESXi hosts (6.5 or 6.7)" msgstr "2 台の ESXi ホスト (6.5 または 6.7)" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:42 msgid "with 2 NIC, the second ones should be available for the test" msgstr "2 つの NIC (テスト用に 2 番目の NIC が利用可能)" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:43 msgid "a VCSA host" msgstr "VCSA ホスト" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:44 msgid "a NFS server" msgstr "NFS サーバー" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:47 msgid "Python dependencies:" msgstr "Python の依存関係:" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:46 msgid "`pyvmomi `_" msgstr "`pyvmomi `_" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:47 msgid "`requests `_" msgstr "`requests `_" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:49 msgid "If you want to deploy your test environment in a hypervisor, both `VMware or Libvirt `_ works well." msgstr "ハイパーバイザーにテスト環境をデプロイする場合は、`VMware または Libvirt ` の両方が正常に機能します。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:52 msgid "NFS server configuration" msgstr "NFS サーバーの設定" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:54 msgid "Your NFS server must expose the following directory structure:" msgstr "NFS サーバーでは、以下のディレクトリー構造を公開する必要があります。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:67 msgid "On a Linux system, you can expose the directory over NFS with the following export file:" msgstr "Linux システムでは、次のエクスポートファイルを使用して、NFS 経由でディレクトリーを公開できます。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:76 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 に合わせて設定を調整してください。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:79 msgid "The service can be enabled with:" msgstr "このサービスは以下で有効にできます。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:87 msgid "Configure your installation" msgstr "インストールの設定" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:89 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 `_:" msgstr "セットアップを説明する構成ファイルを準備します。このファイルは :file:`test/integration/cloud-config-vcenter.ini` という名前し、:file:`test/lib/ansible_test/config/cloud-config-vcenter.ini.template` をベースにする必要があります。たとえば、`vmware-on-libvirt `_ でラボをデプロイした場合は以下のようになります。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:109 msgid "Using an HTTP proxy" msgstr "HTTP プロキシーの使用" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:110 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 つの追加キーを使用して、プロキシーサーバーの場所を指定できます。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:117 msgid "In addition, you may need to adjust the variables of the following `var files `_ 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 ファイル `_ の変数を調整しないといけない場合があります。vmware-on-libvirt を使用してラボを準備する場合は、変更することができません。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:120 msgid "Run the test-suite" msgstr "テストスイートの実行" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:122 msgid "Once your configuration is ready, you can trigger a run with the following command:" msgstr "設定の準備ができたら、以下のコマンドで実行をトリガーできます。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:129 msgid "``vmware_host_firewall_manager`` is the name of the module to test." msgstr "``vmware_host_firewall_manager`` は、テストするモジュールの名前です。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:131 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 `_." msgstr "``vmware_guest`` は、他のテストロールよりもはるかに大きく、速度もかなり遅くなります。`main.yml `_ でテスト Playbook の一部を有効または無効にできます。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:135 msgid "Unit-test" msgstr "ユニットテスト" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:137 msgid "The VMware modules have limited unit-test coverage. You can run the test suite with the following commands:" msgstr "VMware モジュールには、unit-test の範囲が限定されています。以下のコマンドを実行してテストスイートを実行できます。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:146 msgid "Code style and best practice" msgstr "コードスタイルおよびベストプラクティス" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:149 msgid "datacenter argument with ESXi" msgstr "ESXi での datacenter 引数" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:151 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 が間違ったデータセンターをサイレントにターゲットにしていることにユーザーが気付かない可能性があるためです。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:155 msgid "esxi_hostname should not be mandatory" msgstr "esxi_hostname は必須ではない" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:157 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`` パラメーターは任意である必要があります。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:173 msgid "Example should use the fully qualified collection name (FQCN)" msgstr "例では、完全修飾コレクション名 (FQCN) を使用する必要があります" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:175 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`` を使用する必要があります。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:178 msgid "This way, the examples do not depend on the ``collections`` directive of the playbook." msgstr "この方法では、Playbook の ``collections`` ディレクティブに依存しません。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:182 msgid "Functional tests" msgstr "機能テスト" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:185 msgid "Writing new tests" msgstr "新規テストの作成" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:187 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` process." msgstr "統合テストの新しいコレクションを作成している場合は、標準の Ansible の :ref:`統合テスト` プロセス以外に注意すべき VMware 固有の事項がいくつかあります。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:190 msgid "The test-suite uses a set of common, pre-defined vars located `in 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 `_ ロールにある一般的な事前定義済みの変数のセットを使用します。ここに定義されたリソースは、テストの開始時にそのロールをインポートして自動的に作成されます。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:200 msgid "This will give you a ready to use cluster, datacenter, datastores, folder, switch, dvswitch, ESXi hosts, and VMs." msgstr "これにより、クラスター、データセンター、データストア、ディレクトリー、スイッチ、dvSwitch、ESXi ホスト、および仮想マシンを使用する準備が整います。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:203 msgid "No need to create too much resources" msgstr "リソースを過剰に作成する必要なし" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:205 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`` を使用して複数のリソースの作成を行う必要はありません。回避することで、テストの実行を迅速化して、後でクリーンアップを単純化できます。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:209 msgid "VM names should be predictable" msgstr "仮想マシン名は、名前で内容が予測できるものにする" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:211 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`` を使用できます。このように、自動的にクリーンアップされます。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:215 msgid "Avoid the common boiler plate code in your test playbook" msgstr "テスト Playbook で一般的なボイラールのコードを回避" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:217 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 モジュールのデフォルトキーを事前に初期化できます。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:220 msgid "hostname" msgstr "hostname" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:221 msgid "username" msgstr "username" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:222 msgid "password" msgstr "password" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:223 msgid "validate_certs" msgstr "validate_certs" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:225 msgid "For example, the following block:" msgstr "たとえば、以下のブロックの場合:" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:239 msgid "should be simplified to just:" msgstr "以下を単純化する必要があります。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:251 msgid "Typographic convention" msgstr "表記規則" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:254 msgid "Nomenclature" msgstr "命名法" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:256 msgid "We try to enforce the following rules in our documentation:" msgstr "Ansible のドキュメントでは、次のルールを適用しています。" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:258 msgid "VMware, not VMWare or vmware" msgstr "VMware (VMWare または vmware ではありません)" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:259 msgid "ESXi, not esxi or ESXI" msgstr "ESXi (esxi または ESXI ではありません)" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:260 msgid "vCenter, not vcenter or VCenter" msgstr "vCenter (vcenter または VCenter ではありません)" #: ../../rst/dev_guide/platforms/vmware_guidelines.rst:262 msgid "We also refer to vcsim's Go implementation with ``govcsim``. This to avoid any confusion with the outdated implementation." msgstr "また、``govcsim`` を使用した vcsim の Go 実装も参照します。これは、古い実装との混乱を回避するためのものです。" #: ../../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 "The Ansible VMware REST collection (on `Galaxy `_, source code `repository `_) is maintained by Red Hat and the community." msgstr "Ansible VMware REST コレクション (`Galaxy `_ ではソースコード `repository `_) は、Red Hat とコミュニティーにより維持されます。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:13 msgid "Contribution process" msgstr "貢献プロセス" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:15 msgid "The modules of the vmware_rest collection are autogenerated by another tool called `vmware_rest_code_generator `." msgstr "vmware_rest コレクションのモジュールは、`vmware_rest_code_generator ` と呼ばれる別のツールにより自動生成されます。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:17 msgid "If you would like to contribute a change, we would appreciate if you:" msgstr "変更に貢献したい場合は、以下をご用意ください。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:19 msgid "submit a Github Pull Request (PR) against the vmware_rest_code_generator project" msgstr "vmware_rest_code_generator プロジェクトに対して Github Pull Request (PR) を送信します。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:20 msgid "but also ensure the generated modules are compliant with our quality criteria." msgstr "ただし、生成されたモジュールが品質基準に準拠していることを確認します。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:25 msgid "You will need:" msgstr "以下が必要になります。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:27 msgid "Python 3.6 or greater" msgstr "Python 3.6 以降" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:28 msgid "the `tox ` command" msgstr "`tox ` コマンド" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:32 msgid "vmware_rest_code_generator" msgstr "vmware_rest_code_generator" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:34 msgid "Your contribution should follow the coding style of `Black `. To run the code formatter, just run:" msgstr "貢献は、`Black ` のコーディングスタイルに従う必要があります。コードフォーマッターを実行するには、以下を実行します。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:41 msgid "To regenerate the vmware_rest collection, you can use the following commands:" msgstr "vmware_rest コレクションを再生成するには、以下のコマンドを使用できます。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:47 msgid "If you also want to update the EXAMPLE section of the modules, run:" msgstr "モジュールの EXAMPLE セクションも更新する場合は、以下を実行します。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:54 msgid "Testing with ansible-test" msgstr "ansible-test を使用したテスト" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:56 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/` に置かれます。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:58 msgid "To run the tests, you will need a vcenter instance and an ESXi." msgstr "テストを実行するには、vcenter インスタンスと ESXi が必要です。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:61 msgid "black code formatter" msgstr "ブラックコードフォーマッター" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:63 msgid "We follow the coding style of `Black `. You can run the code formatter with the following command." msgstr "`Black ` のコーディングスタイルに準拠しています。以下のコマンドでコードフォーマッターを実行できます。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:72 msgid "sanity tests" msgstr "健全性テスト" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:74 msgid "Here we use Python 3.8, the minimal version is 3.6." msgstr "ここでは Python 3.8 を使用します。最小バージョンは 3.6 です。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:83 msgid "integration tests" msgstr "統合テスト" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:85 msgid "These tests should be run against your test environment." msgstr "これらのテストは、テスト環境に対して実行する必要があります。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:87 msgid "..warning:: The test suite will delete all the existing DC from your test environment." msgstr "..警告:: テストスイートは、テスト環境から既存の DC をすべて削除します。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:89 msgid "First, prepare a configuration file, we call it :file:`/tmp/inventory-vmware_rest` in this example:" msgstr "まず設定ファイルを準備し、この例では :file:`/tmp/inventory-vmware_rest` とします。" #: ../../rst/dev_guide/platforms/vmware_rest_guidelines.rst:106 msgid "To run the tests, use the following command. You may want to adjust the Python version." msgstr "テストを実行するには、以下のコマンドを使用して Python バージョンを調整できます。" #: ../../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 `_::" msgstr "code または command スニペットの場合は、RST の `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 "箇条書きに他の文章が含まれる場合は、(上の例のような単純なリストでない限り) 箇条書きが完全な文になっていなくてもピリオドを追加します。この理由の 1 つは、各箇条書きが元の文を完了すると言われているためです。" #: ../../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」または「say」だけを使用してください。それ以外は、引用の邪魔になり、編集される傾向があるためです。" #: ../../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." #: ../../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 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:83 msgid "Header notation" msgstr "ヘッダーの表記法" #: ../../rst/dev_guide/style_guide/index.rst:85 msgid "`Section headers in reStructuredText `_ 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 `_ は、さまざまな表記を使用できます。Sphinx は、ヘッダーの階層を作成するときに「オンザフライで学習」します。ドキュメントを読みやすく、編集できるようにするために、標準のヘッダー表記法に従います。以下を使用します。" #: ../../rst/dev_guide/style_guide/index.rst:91 msgid "``###`` with overline, for parts:" msgstr "``###`` 上線付き (各部分の場合):" #: ../../rst/dev_guide/style_guide/index.rst:99 msgid "``***`` with overline, for chapters:" msgstr "``***`` 上線付き (章の場合):" #: ../../rst/dev_guide/style_guide/index.rst:107 msgid "``===`` for sections:" msgstr "``===`` セクションの場合:" #: ../../rst/dev_guide/style_guide/index.rst:114 msgid "``---`` for subsections:" msgstr "``---`` サブセクションの場合:" #: ../../rst/dev_guide/style_guide/index.rst:121 msgid "``^^^`` for sub-subsections:" msgstr "``^^^`` サブサブセクションの場合:" #: ../../rst/dev_guide/style_guide/index.rst:128 msgid "``\"\"\"`` for paragraphs:" msgstr "``\"\"\"`` パラグラフの場合:" #: ../../rst/dev_guide/style_guide/index.rst:137 msgid "Syntax highlighting - Pygments" msgstr "構文の強調表示 - Pygment" #: ../../rst/dev_guide/style_guide/index.rst:139 msgid "The Ansible documentation supports a range of `Pygments lexers `_ for `syntax highlighting `_ to make our code examples look good. Each code-block must be correctly indented and surrounded by blank lines." msgstr "Ansible ドキュメントは、コード例の見栄えを良くするため、`構文の強調表示 `_ の `Pygments lexers `_ の範囲をサポートします。コードブロックは適切にインデントされ、空の行で囲む必要があります。" #: ../../rst/dev_guide/style_guide/index.rst:142 msgid "The Ansible documentation allows the following values:" msgstr "Ansible ドキュメントでは、以下の値を使用できます。" #: ../../rst/dev_guide/style_guide/index.rst:144 msgid "none (no highlighting)" msgstr "なし (強調表示なし)" #: ../../rst/dev_guide/style_guide/index.rst:145 msgid "ansible-output (a custom lexer for Ansible output)" msgstr "ansible-output (Ansible 出力用のカスタム lexer)" #: ../../rst/dev_guide/style_guide/index.rst:146 msgid "bash" msgstr "bash" #: ../../rst/dev_guide/style_guide/index.rst:147 msgid "console" msgstr "console" #: ../../rst/dev_guide/style_guide/index.rst:148 msgid "csharp" msgstr "csharp" #: ../../rst/dev_guide/style_guide/index.rst:149 msgid "ini" msgstr "ini" #: ../../rst/dev_guide/style_guide/index.rst:151 msgid "powershell" msgstr "powershell" #: ../../rst/dev_guide/style_guide/index.rst:152 msgid "python" msgstr "python" #: ../../rst/dev_guide/style_guide/index.rst:153 msgid "rst" msgstr "rst" #: ../../rst/dev_guide/style_guide/index.rst:154 msgid "sh" msgstr "sh" #: ../../rst/dev_guide/style_guide/index.rst:155 msgid "shell" msgstr "shell" #: ../../rst/dev_guide/style_guide/index.rst:156 msgid "shell-session" msgstr "shell-session" #: ../../rst/dev_guide/style_guide/index.rst:157 msgid "text" msgstr "text" #: ../../rst/dev_guide/style_guide/index.rst:158 msgid "yaml" msgstr "yaml" #: ../../rst/dev_guide/style_guide/index.rst:159 msgid "yaml+jinja" msgstr "yaml+jinja" #: ../../rst/dev_guide/style_guide/index.rst:161 msgid "For example, you can highlight Python code using following syntax:" msgstr "たとえば、以下の構文を使用して Python コードを強調表示できます。" #: ../../rst/dev_guide/style_guide/index.rst:171 msgid "Internal navigation" msgstr "内部ナビゲーション" #: ../../rst/dev_guide/style_guide/index.rst:173 msgid "`Anchors (also called labels) and links `_ 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 "`Anchors (also called labels) and links `関連コンテンツを見つけやすくするために、あるローカルテーブルも必要な情報に移動するのに役立ちます。すべての内部リンクで ``:ref:`` 構文を使用する必要があります。また、内部ページには内部 ``:ref:`` リンクに対応するアンカーは 1 つ以上ある必要があります。長いページまたは複数のヘッダーレベルを持つページでも、ローカルの TOC を含めることもできます。" #: ../../rst/dev_guide/style_guide/index.rst:183 msgid "Adding anchors" msgstr "アンカーの追加" #: ../../rst/dev_guide/style_guide/index.rst:185 msgid "Include at least one anchor on every page" msgstr "すべてのページに少なくとも 1 つのアンカーを含める。" #: ../../rst/dev_guide/style_guide/index.rst:186 msgid "Place the main anchor above the main header" msgstr "メインヘッダーの上にメインアンカーを配置する。" #: ../../rst/dev_guide/style_guide/index.rst:187 msgid "If the file has a unique title, use that for the main page anchor::" msgstr "このファイルに一意のタイトルがある場合は、メインページのアンカーに使用する。" #: ../../rst/dev_guide/style_guide/index.rst:191 msgid "You may also add anchors elsewhere on the page" msgstr "ページにアンカーを追加することもできます。" #: ../../rst/dev_guide/style_guide/index.rst:194 msgid "Adding internal links" msgstr "内部リンクの追加" #: ../../rst/dev_guide/style_guide/index.rst:196 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:203 msgid "The second example adds custom text for the link." msgstr "2 つ目の例は、リンクのカスタムテキストを追加します。" #: ../../rst/dev_guide/style_guide/index.rst:206 msgid "Adding links to modules and plugins" msgstr "モジュールおよびプラグインへのリンクの追加" #: ../../rst/dev_guide/style_guide/index.rst:208 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:214 msgid "For example:" msgstr "たとえば、以下のようになります。" #: ../../rst/dev_guide/style_guide/index.rst:220 msgid "displays as :ref:`ansible.builtin.first_found lookup plugin `." msgstr ":ref:`ansible.builtin.first_found lookup plugin ` として表示します。" #: ../../rst/dev_guide/style_guide/index.rst:222 msgid "Modules require different suffixes from other plugins:" msgstr "モジュールには、他のプラグインとは異なるサフィックスが必要です。" #: ../../rst/dev_guide/style_guide/index.rst:224 msgid "Module links use this extended FQCN module name with ``_module`` for the anchor." msgstr "モジュールリンクはこの広範な FQCN モジュール名に続けて、アンカーに ``_module`` を使用します。" #: ../../rst/dev_guide/style_guide/index.rst:225 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:234 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:239 msgid "Adding local TOCs" msgstr "ページ内目次の追加" #: ../../rst/dev_guide/style_guide/index.rst:241 msgid "The page you're reading includes a `local TOC `_. If you include a local TOC:" msgstr "読み取りするページには `ローカル TOC `_ が含まれます。ローカルの TOC を含める場合は、以下のようになります。" #: ../../rst/dev_guide/style_guide/index.rst:244 msgid "place it below, not above, the main heading and (optionally) introductory text" msgstr "目次の下に、主要な見出しと (任意で) 紹介文を追加する。" #: ../../rst/dev_guide/style_guide/index.rst:245 msgid "use the ``:local:`` directive so the page's main header is not included" msgstr "そのページの主要なヘッダーが含まれないように ``:local:`` ディレクティブを使用する。" #: ../../rst/dev_guide/style_guide/index.rst:246 msgid "do not include a title" msgstr "タイトルは除外する。" #: ../../rst/dev_guide/style_guide/index.rst:248 msgid "The syntax is:" msgstr "構文は以下のようになります。" #: ../../rst/dev_guide/style_guide/index.rst:256 msgid "More resources" msgstr "参考資料" #: ../../rst/dev_guide/style_guide/index.rst:258 msgid "These pages offer more help with grammatical, stylistic, and technical rules for documentation." msgstr "以下のページでは、ドキュメントに関する文法、スタイル、および技術的なルールを紹介しています。" #: ../../rst/dev_guide/style_guide/index.rst:273 msgid ":ref:`community_documentation_contributions`" msgstr ":ref:`community_documentation_contributions`" #: ../../rst/dev_guide/style_guide/index.rst:274 msgid "How to contribute to the Ansible documentation" msgstr "Ansible ドキュメントへの貢献方法" #: ../../rst/dev_guide/style_guide/index.rst:275 msgid ":ref:`testing_documentation_locally`" msgstr ":ref:`testing_documentation_locally`" #: ../../rst/dev_guide/style_guide/index.rst:276 msgid "How to build the Ansible documentation" msgstr "Ansible ドキュメントのビルド方法" #: ../../rst/dev_guide/style_guide/index.rst:278 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`" msgstr "* 「:ref:`Ansible ドキュメント`」のスタイルに従ってください。" #: ../../rst/dev_guide/style_guide/resources.rst:4 msgid "Ask for advice on IRC, on the ``#ansible-devel`` Freenode channel" msgstr "Freenode チャンネル ``#ansible-devel`` の 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 `_" msgstr "`AP Stylebook `_" #: ../../rst/dev_guide/style_guide/resources.rst:8 msgid "`Chicago Manual of Style `_" msgstr "`Chicago Manual of Style `_" #: ../../rst/dev_guide/style_guide/resources.rst:9 msgid "`Strunk and White's Elements of Style `_" msgstr "`Strunk and White's Elements of Style `_" #: ../../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 Blob にリンクしないでください。" #: ../../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 "検索の最適化" #: ../../rst/dev_guide/style_guide/search_hints.rst:22 msgid "Findable documentation" msgstr "検索可能なドキュメント" #: ../../rst/dev_guide/style_guide/search_hints.rst:23 msgid "Writing for findability" msgstr "見やすくするために記述" #: ../../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 "注意の 1 つの単語 - 見出しのサイズを制限する場合は、`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 `_ 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 は、検索結果の上部に `feature snippet `_ を追加して検索結果を最適化できます。このスニペットは、最初の検索結果に関するドキュメントに小さなウィンドウを提供し、残りの検索結果よりも詳細を追加し、時には読者の質問にその場で答えたり、少なくともリンク先のページが読者の探しているものであることを確認することができます。" #: ../../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 ` 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 ` を使用すると、読者がページ上部のヘッダーをスキャンして、探しているセクションにクリックできるため、この問題を軽減することができます。重要な文書については、検索結果のページに直接アクセスできる新しいページを作成することを検討してください。" #: ../../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, Source-Navigator, and Ansible Tower. When used as a command, use lowercase as appropriate, such as \"To start GCC, type ``gcc``.\"" msgstr "固有名詞として使用する場合は、GNUPro、Source-Navigator、Ansible Tower のように製品の大文字を使用します。コマンドとして使用する場合は、「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 "Ansibleは、" #: ../../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 is a registered trademark of 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 "詳細は、" #: ../../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 "ユーザー" #: ../../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 "ユーザー名" #: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:274 msgid "Correct. Do not use \"user name.\"" msgstr "適切です。「ユーザー名」は使用しないでください。" #: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:277 msgid "View" msgstr "表示" #: ../../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 のどちらの記号を使用するのが適切かは、製品が商品用かサービス用かによって異なります。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 Tower® or Ansible®, on first reference when referring to products." msgstr "製品を最初に参照する際に、Red Hat® Ansible Tower® または 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 Tower® system performance is incredible." msgstr "正: Red Hat® Ansible Tower® system performance is incredible." #: ../../rst/dev_guide/style_guide/trademarks.rst:43 msgid "Incorrect: Ansible's performance is incredible." msgstr "適切ではありません。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 Tower®.\"" msgstr "正: \"Orchestrate your entire network using Red Hat® Ansible Tower®.\"" #: ../../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 Tower® configuration software is surging.\"" msgstr "正: \"Corporate demand for Red Hat® Ansible Tower® configuration software is surging.\"" #: ../../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:84 msgid "Ansible Tower®" msgstr "Ansible Tower®" #: ../../rst/dev_guide/style_guide/trademarks.rst:87 msgid "Other Common Trademarks and Resource Sites:" msgstr "その他の一般的な商標およびリソースのサイト:" #: ../../rst/dev_guide/style_guide/trademarks.rst:88 msgid "Linux is a registered trademark of Linus Torvalds." msgstr "Linux は、Linus Torvalds の登録商標です。" #: ../../rst/dev_guide/style_guide/trademarks.rst:89 msgid "UNIX® is a registered trademark of The Open Group." msgstr "UNIX® は、The Open Group の登録商標です。" #: ../../rst/dev_guide/style_guide/trademarks.rst:90 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:91 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:92 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:93 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:94 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:95 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, Shippable) 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 プル要求は、バグの動作を示すさまざまなテスト (Shippableなど) を自動的に実行します。ただし、貢献者は、自動化された 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:541 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:44 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 の問題を確認し、バグ修正を手伝うことです。バグ修正は、ほとんど常に、機能開発よりも優先されるためです。" #: ../../rst/dev_guide/testing.rst:48 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 プル要求も、大きな助けになるでしょう。" #: ../../rst/dev_guide/testing.rst:55 msgid "Testing within GitHub & Shippable" msgstr "GitHub および Shippable でのテスト" #: ../../rst/dev_guide/testing.rst:59 msgid "Organization" msgstr "組織" #: ../../rst/dev_guide/testing.rst:61 msgid "When Pull Requests (PRs) are created they are tested using Shippable, a Continuous Integration (CI) tool. Results are shown at the end of every PR." msgstr "プル要求 (PR: Pull Requests) が作成されると、継続的インテグレーション (CI) ツールである Shippable を使用してテストが行われます。結果はすべての PR の最後に表示されます。" #: ../../rst/dev_guide/testing.rst:63 msgid "When Shippable 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 "Saltppable がエラーを検出し、それが PR で変更されたファイルにリンクされると、関連する行が GitHub のコメントとして追加されます。たとえば、以下のようになります。" #: ../../rst/dev_guide/testing.rst:72 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 Shippable, for example:" msgstr "上記の例から、``--test pep8`` および ``--test validate-modules`` が問題を特定したことが分かります。与えられたコマンドを使用すると、同じテストをローカルで実行して、変更を GitHub にプッシュして Shippable を待つことなく、すべての問題を修正したことを確認できます。次に例を示します。" #: ../../rst/dev_guide/testing.rst:74 msgid "If you haven't already got Ansible available, use the local checkout by running::" msgstr "Ansible がまだ利用できるようになっていない場合は、ローカルでチェックアウトを実行してください。" #: ../../rst/dev_guide/testing.rst:78 msgid "Then run the tests detailed in the GitHub comment::" msgstr "次に、GitHub コメントで説明するテストを実行します。" #: ../../rst/dev_guide/testing.rst:83 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:86 msgid "Rerunning a failing CI job" msgstr "失敗した CI ジョブの再実行" #: ../../rst/dev_guide/testing.rst:88 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:90 msgid "a temporary issue accessing an external resource, such as a yum or git repo" msgstr "yum や git リポジトリーなどの外部リソースにアクセスする際に一時的に問題が発生した場合。" #: ../../rst/dev_guide/testing.rst:91 msgid "a timeout creating a virtual machine to run the tests on" msgstr "テストを実行するための仮想マシンを作成するタイムアウト。" #: ../../rst/dev_guide/testing.rst:93 msgid "If either of these issues appear to be the case, you can rerun the Shippable test by:" msgstr "いずれかの問題が発生しているようであれば、以下の方法で Shippable テストを再実行できます。" #: ../../rst/dev_guide/testing.rst:95 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:96 msgid "closing and re-opening the PR (full rebuild)" msgstr "PR を閉じて再度開く (完全な再構築)" #: ../../rst/dev_guide/testing.rst:97 msgid "making another change to the PR and pushing to GitHub" msgstr "PR に何らかの変更を加えて GitHub にプッシュする。" #: ../../rst/dev_guide/testing.rst:99 msgid "If the issue persists, please contact us in ``#ansible-devel`` on Freenode IRC." msgstr "問題が解決しない場合は、Freenode IRC の ``#ansible-devel`` にお問い合わせください。" #: ../../rst/dev_guide/testing.rst:103 msgid "How to test a PR" msgstr "PR をテストする方法" #: ../../rst/dev_guide/testing.rst:105 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:107 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:110 msgid "Setup: Checking out a Pull Request" msgstr "設定: プル要求のチェック" #: ../../rst/dev_guide/testing.rst:112 msgid "You can do this by:" msgstr "これは、以下の方法で実行できます。" #: ../../rst/dev_guide/testing.rst:114 msgid "checking out Ansible" msgstr "Ansible のチェックアウト" #: ../../rst/dev_guide/testing.rst:115 msgid "fetching the proposed changes into a test branch" msgstr "テストブランチへの提案された変更の取得" #: ../../rst/dev_guide/testing.rst:116 msgid "testing" msgstr "テスト" #: ../../rst/dev_guide/testing.rst:117 msgid "commenting on that particular issue on GitHub" msgstr "GitHub に特定の問題についてのコメント" #: ../../rst/dev_guide/testing.rst:119 msgid "Here's how:" msgstr "以下に、実行する方法を説明します。" #: ../../rst/dev_guide/testing.rst:122 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:129 msgid "Create a fresh area to work::" msgstr "作業用に新しい領域を作成します::" #: ../../rst/dev_guide/testing.rst:135 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:139 msgid "Only test ``ansible:devel``" msgstr "``ansible:devel`` のみをテストします。" #: ../../rst/dev_guide/testing.rst:141 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:143 msgid "Use the pull request number when you fetch the proposed changes and create your branch for testing::" msgstr "提案された変更を取得し、テスト用にブランチを作成するときにプル要求番号を使用します。" #: ../../rst/dev_guide/testing.rst:148 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:151 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:154 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:156 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:159 msgid "Simply source it (to use the Linux/Unix terminology) to begin using it immediately::" msgstr "ソースを作成するだけ (Linux/Unix の用語を使用するために) で、すぐに使い始めることができます。" #: ../../rst/dev_guide/testing.rst:163 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:167 msgid "Testing the Pull Request" msgstr "プル要求のテスト" #: ../../rst/dev_guide/testing.rst:169 msgid "At this point, you should be ready to begin testing!" msgstr "この時点でテストを開始する準備が整いました。" #: ../../rst/dev_guide/testing.rst:171 msgid "Some ideas of what to test are:" msgstr "何をテストするかのアイデアをいくつか挙げてみましょう。" #: ../../rst/dev_guide/testing.rst:173 msgid "Create a test Playbook with the examples in and check if they function correctly" msgstr "例題を含むテスト Playbook を作成し、それらが正しく機能するかどうかを確認します。" #: ../../rst/dev_guide/testing.rst:174 msgid "Test to see if any Python backtraces returned (that's a bug)" msgstr "Python のバックトレースが返されているかどうかをテストします (これはバグです)。" #: ../../rst/dev_guide/testing.rst:175 msgid "Test on different operating systems, or against different library versions" msgstr "異なるオペレーティングシステムで、または異なるバージョンのライブラリーに対してテストします。" #: ../../rst/dev_guide/testing.rst:178 msgid "Run sanity tests" msgstr "健全性テストの実行" #: ../../rst/dev_guide/testing.rst:184 msgid "More information: :ref:`testing_sanity`" msgstr "詳細情報: :ref:`testing_sanity`" #: ../../rst/dev_guide/testing.rst:187 msgid "Run unit tests" msgstr "ユニットテストの実行" #: ../../rst/dev_guide/testing.rst:193 msgid "More information: :ref:`testing_units`" msgstr "詳細情報: :ref:`testing_units`" #: ../../rst/dev_guide/testing.rst:196 msgid "Run integration tests" msgstr "インテグレーションテストの実行" #: ../../rst/dev_guide/testing.rst:202 msgid "More information: :ref:`testing_integration`" msgstr "詳細情報: :ref:`testing_integration`" #: ../../rst/dev_guide/testing.rst:204 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:206 msgid "Example::" msgstr "例:" #: ../../rst/dev_guide/testing.rst:210 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:223 msgid "Code Coverage Online" msgstr "オンラインのコードカバレージ" #: ../../rst/dev_guide/testing.rst:225 msgid "`The online code coverage reports `_ 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 "`The online code coverage reports `_ は、Ansible でテストが向上する領域を特定するのが適切な方法です。赤い色に従うことで、レポートをドリルダウンして、テストがまったくないファイルを見つけることができます。コードがどのように機能するかを明確に示す統合テストとユニットテストの両方を追加し、重要な Ansible 関数を検証し、存在しない領域でのテスト範囲を拡大することは、Ansible の改善に役立つ貴重な方法です。" #: ../../rst/dev_guide/testing.rst:232 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:240 msgid "Want to know more about testing?" msgstr "テストに関する詳細情報" #: ../../rst/dev_guide/testing.rst:242 msgid "If you'd like to know more about the plans for improving testing Ansible then why not join the `Testing Working Group `_." msgstr "Ansible テストを改善する詳細な計画を確認したい場合は、`テストワーキンググループ `_ にご参加ください。" #: ../../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-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/_data/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/_data/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 `_." msgstr "`antsibull-changelog lint `_ を使用した 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/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`` ファイルは使用されません。他の (module_utils) 場合は、空の ``__init__.py`` を許可する Python 名前空間を使用することも可能です。" #: ../../rst/dev_guide/testing/sanity/empty-init.rst:8 msgid "``lib/ansible/modules/``" msgstr "``lib/ansible/modules/``" #: ../../rst/dev_guide/testing/sanity/empty-init.rst:9 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 `_" msgstr "`Absolute and relative imports `_" #: ../../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 `_" msgstr "`Changing the division operator `_" #: ../../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 `_" msgstr "`Make print a function `_" #: ../../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 `_ 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 "健全性テストにより、コンテンツの処理時にトレースバックが発生すると、そのエラーは無視できません。このような場合には、新しい `バグレポート `_ を作成し、問題を修正してください。コンテンツに問題があるためにトレースバックが発生した場合は、その問題を修正する必要があります。コンテンツが正しい場合は、健全性テストのバグが修正されるまで、テストをスキップする必要があります。" #: ../../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 コレクションのエントリーを無視します。" #: ../../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:90 msgid "Ignore File Errors" msgstr "ignore ファイルエラー" #: ../../rst/dev_guide/testing/sanity/ignores.rst:92 msgid "There are various errors that can be reported for the ignore file itself:" msgstr "ignore ファイル自体について報告できるさまざまなエラーがあります。" #: ../../rst/dev_guide/testing/sanity/ignores.rst:94 msgid "syntax errors parsing the ignore file" msgstr "ignore ファイルを解析する構文エラー" #: ../../rst/dev_guide/testing/sanity/ignores.rst:95 msgid "references a file path that does not exist" msgstr "存在しないファイルパスを参照" #: ../../rst/dev_guide/testing/sanity/ignores.rst:96 msgid "references to a sanity test that does not exist" msgstr "存在しない健全性テストへの参照" #: ../../rst/dev_guide/testing/sanity/ignores.rst:97 msgid "ignoring an error that does not occur" msgstr "発生しないエラーを無視" #: ../../rst/dev_guide/testing/sanity/ignores.rst:98 msgid "ignoring a file which is skipped" msgstr "省略されるファイルを無視" #: ../../rst/dev_guide/testing/sanity/ignores.rst:99 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 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 "collections:" #: ../../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 `_ for a list), unchecked imports are only allowed from the Python standard library, from dependencies of ansible-core, and from ansible-core itself." msgstr "``plugins/`` のその他のディレクトリー (一覧は「`コミュニティーコレクション要件 `_」を参照) では、チェックされていないインポートは Python 標準ライブラリー、ansible-core の依存関係、および ansible-core 自体からのみ許可されます。" #: ../../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 `." msgstr "これらのテストの実行方法は、:ref:`サニティーテストガイド ` を参照してください。" #: ../../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: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/2008`` - Skip tests on Windows Server 2008." msgstr "``skip/windows/2008`` - Windows Server 2008 のテストを省略します。" #: ../../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 "不安定" #: ../../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 のメンバーによって不安定としてマークされます。GitHub 問題_ が作成され、不安定な各テストを追跡します。" #: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:117 msgid "Disabled" msgstr "無効" #: ../../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 "サポート対象外" #: ../../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 "ただし、テストが使用できない場合は、サポート対象外としてテストをマークすると、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/foreman``" msgstr "``cloud/foreman``" #: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:159 msgid "``cloud/openshift``" msgstr "``cloud/openshift``" #: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:160 msgid "``cloud/tower``" msgstr "``cloud/tower``" #: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:161 msgid "``cloud/vcenter``" msgstr "``cloud/vcenter``" #: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:164 msgid "Untested" msgstr "未テスト" #: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:166 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:169 msgid "Issues" msgstr "問題" #: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:171 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:174 msgid "`AWS `_" msgstr "`AWS `_" #: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:175 msgid "`Azure `_" msgstr "`Azure `_" #: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:176 msgid "`Windows `_" msgstr "`Windows `_" #: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:177 msgid "`General `_" msgstr "`General `_" #: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:180 msgid "Questions" msgstr "ご質問はございますか。" #: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:182 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`` にお問い合わせください。" #: ../../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/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._text`` contains several functions that may be even better for you: ``to_text``, ``to_bytes``, and ``to_native``." msgstr "これが文字列を特定の型に変換するコードの一部である場合、``ansible.module_utils._text`` には、より良い関数がいくつか含まれています (``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:11 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 の理解を深めるために概念を区別し、それぞれが適切に使用される場所を示すためのものです。" #: ../../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/_data/sanity/`` instead." msgstr "``test/sanity/`` (例外あり) のサブディレクトリーのほとんどは、代わりに ``test/lib/ansible_test/_data/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 `_." msgstr "`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-base's ``lib/ansible/config/ansible_builtin_runtime.yml``" msgstr "ansible-base の ``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 `_ tool." msgstr "優れた `shellcheck `_ ツールを使用してシェルスクリプトの静的コード分析。" #: ../../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 ` 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 ` の使用を探します。見つかった場合は、モジュールの 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:66 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 `_. Requirements files are named after their respective commands. See also the `constraints `_ applicable to all commands." msgstr "要件の一覧は `test/lib/ansible_test/_data/requirements `_ に記載されています。要件ファイルには、各コマンドにちなんで名前が付けられています。全コマンドに適用される `制約 `_ も参照してください。" #: ../../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 `_ so it can be discussed." msgstr "コンパイルテストに変更が必要な場合は、`ワーキンググループのテストの議題 `_ にコメントを追加してください。その内容について話し合うことができます。" #: ../../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 `." msgstr "メインの Ansible リポジトリーに組み込むモジュールを送信する前に、正しい HTML レンダリングついてモジュールドキュメントをテストする必要があります。また、argspec が Python ファイルのドキュメントと一致することを確認する必要があります。コミュニティーページでは、「:ref:`reStructuredText ドキュメントのテスト `」の詳細が提供されています。" #: ../../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 `." msgstr ":ref:`開発環境 ` が稼働していることを確認します。" #: ../../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 `_ repository." msgstr "ソースファイルは `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 `_ to avoid duplicated effort." msgstr "``httptester`` を改善するタイミングがある場合は、重複作業を回避するために、「`ワーキンググループのテストの議題 `_」にコメントを追加します。" #: ../../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: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:41 msgid "You can also call ``ansible-test`` with the full path::" msgstr "完全パスで ``ansible-test`` を呼び出すこともできます。" #: ../../rst/dev_guide/testing_integration.rst:46 msgid "integration_config.yml" msgstr "integration_config.yml" #: ../../rst/dev_guide/testing_integration.rst:48 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:55 msgid "Prerequisites" msgstr "要件" #: ../../rst/dev_guide/testing_integration.rst:57 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:61 msgid "(Complete list pending)" msgstr "(完全はリストは後に追加されます)" #: ../../rst/dev_guide/testing_integration.rst:64 msgid "Non-destructive Tests" msgstr "非破壊テスト" #: ../../rst/dev_guide/testing_integration.rst:66 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:69 msgid "Running integration tests within Docker" msgstr "*Docker 内での統合テストの実行" #: ../../rst/dev_guide/testing_integration.rst:71 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 centos8``. See the `list of supported docker images `_ 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 centos8``)。オプションについては、「`サポート対象外の docker イメージ `_」を参照してください (``default``イメージは、健全性とユニットテスト、およびクラウドモジュールなどのプラットフォームに依存しない統合テストに使用されます)。" #: ../../rst/dev_guide/testing_integration.rst:73 msgid "Avoiding pulling new Docker images" msgstr "新規 Docker イメージのプルの回避" #: ../../rst/dev_guide/testing_integration.rst:75 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`` オプションを使用します。これは、ダウンロードに利用できないカスタムのローカルイメージを使用する場合に必要です。" #: ../../rst/dev_guide/testing_integration.rst:77 msgid "Run as follows for all POSIX platform tests executed by our CI system in a fedora32 docker container::" msgstr "fedora32 docker コンテナーで CI システムによって実行されるすべての POSIX プラットフォームテストに対して次のように実行します。" #: ../../rst/dev_guide/testing_integration.rst:81 msgid "You can target a specific tests as well, such as for individual modules::" msgstr "個々のモジュールなど、特定のテストを対象とすることもできます。" #: ../../rst/dev_guide/testing_integration.rst:85 msgid "You can use the ``-v`` option to make the output more verbose::" msgstr "``-v`` オプションを使用すると、出力をさらに詳細にすることができます。" #: ../../rst/dev_guide/testing_integration.rst:89 msgid "Use the following command to list all the available targets::" msgstr "利用可能なターゲットの一覧を表示するには、以下のコマンドを実行します。" #: ../../rst/dev_guide/testing_integration.rst:93 msgid "Bash users" msgstr "Bash ユーザー" #: ../../rst/dev_guide/testing_integration.rst:95 msgid "If you use ``bash`` with ``argcomplete``, obtain a full list by doing: ``ansible-test integration ``" msgstr "``bash`` を ``argcomplete`` とともに使用する場合は、``ansible-test integration `` を実行して完全な一覧を取得します。" #: ../../rst/dev_guide/testing_integration.rst:98 msgid "Destructive Tests" msgstr "破壊テスト" #: ../../rst/dev_guide/testing_integration.rst:100 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:106 msgid "Windows Tests" msgstr "Windows テスト" #: ../../rst/dev_guide/testing_integration.rst:108 msgid "These tests exercise the ``winrm`` connection plugin and Windows modules. You'll need to define an inventory with a remote Windows 2008 or 2012 Server to use for testing, and enable PowerShell Remoting to continue." msgstr "これらのテストは、``winrm`` 接続プラグインと Windows モジュールに従います。テストに使用するリモート Windows 2008 Server または 2012 Server を持つインベントリーを定義し、PowerShell Remoting を継続できるようにする必要があります。" #: ../../rst/dev_guide/testing_integration.rst:112 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:115 msgid "Enable PowerShell Remoting (run on the Windows host via Remote Desktop)::" msgstr "PowerShell Remoting を有効にします (リモートデスクトップを介して Windows ホストで実行します)::" #: ../../rst/dev_guide/testing_integration.rst:119 msgid "Define Windows inventory::" msgstr "Windows インベントリーを定義します。" #: ../../rst/dev_guide/testing_integration.rst:124 msgid "Run the Windows tests executed by our CI system::" msgstr "CI システムで実行する Windows テストを実行します::" #: ../../rst/dev_guide/testing_integration.rst:129 msgid "Tests in Docker containers" msgstr "Docker コンテナーでのテスト" #: ../../rst/dev_guide/testing_integration.rst:131 msgid "If you have a Linux system with Docker installed, running integration tests using the same Docker containers used by the Ansible continuous integration (CI) system is recommended." msgstr "Docker がインストールされた Linux システムをお持ちの場合は、Ansible の継続的インテグレーション (CI) システムで使用されているものと同じ Docker コンテナーを使用して統合テストを実行することが推奨されます。" #: ../../rst/dev_guide/testing_integration.rst:134 msgid "Docker on non-Linux" msgstr "Linux 以外の Docker" #: ../../rst/dev_guide/testing_integration.rst:136 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:141 msgid "Running Integration Tests" msgstr "統合テストの実行" #: ../../rst/dev_guide/testing_integration.rst:143 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:147 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:153 msgid "Container Images" msgstr "コンテナーイメージ" #: ../../rst/dev_guide/testing_integration.rst:156 msgid "Python 2" msgstr "Python 2" #: ../../rst/dev_guide/testing_integration.rst:158 msgid "Most container images are for testing with Python 2:" msgstr "ほとんどのコンテナーイメージは、Python 2 でテストするためのものです。" #: ../../rst/dev_guide/testing_integration.rst:160 msgid "centos6" msgstr "centos6" #: ../../rst/dev_guide/testing_integration.rst:161 msgid "centos7" msgstr "centos7" #: ../../rst/dev_guide/testing_integration.rst:162 msgid "fedora28" msgstr "fedora28" #: ../../rst/dev_guide/testing_integration.rst:163 msgid "opensuse15py2" msgstr "opensuse15py2" #: ../../rst/dev_guide/testing_integration.rst:164 msgid "ubuntu1404" msgstr "ubuntu1404" #: ../../rst/dev_guide/testing_integration.rst:165 msgid "ubuntu1604" msgstr "ubuntu1604" #: ../../rst/dev_guide/testing_integration.rst:168 msgid "Python 3" msgstr "Python 3" #: ../../rst/dev_guide/testing_integration.rst:170 msgid "To test with Python 3 use the following images:" msgstr "Python 3 でテストするには、以下のイメージを使用します。" #: ../../rst/dev_guide/testing_integration.rst:172 msgid "centos8" msgstr "centos8" #: ../../rst/dev_guide/testing_integration.rst:173 msgid "fedora32" msgstr "fedora32" #: ../../rst/dev_guide/testing_integration.rst:174 msgid "opensuse15" msgstr "opensuse15" #: ../../rst/dev_guide/testing_integration.rst:175 msgid "ubuntu1804" msgstr "ubuntu1804" #: ../../rst/dev_guide/testing_integration.rst:179 msgid "Legacy Cloud Tests" msgstr "レガシーのクラウドテスト" #: ../../rst/dev_guide/testing_integration.rst:181 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:186 msgid "Other configuration for Cloud Tests" msgstr "クラウドテストのその他の設定" #: ../../rst/dev_guide/testing_integration.rst:188 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:194 #: ../../rst/dev_guide/testing_integration_legacy.rst:58 msgid "IAM policies for AWS" msgstr "AWS の IAM ポリシー" #: ../../rst/dev_guide/testing_integration.rst:196 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:199 msgid "testing-policies" msgstr "testing-policies" #: ../../rst/dev_guide/testing_integration.rst:201 msgid "The GitHub repository `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 `_ には、既存の AWS モジュールの統合テストに使用するポリシーのセットが 2 つ含まれます。Playbook `hacking/aws_config/setup_iam.yml` を使用すると、2 つのグループを設定できます。" #: ../../rst/dev_guide/testing_integration.rst:205 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:208 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:212 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:220 #: ../../rst/dev_guide/testing_integration_legacy.rst:76 msgid "Other Definitions required" msgstr "その他の必要な定義" #: ../../rst/dev_guide/testing_integration.rst:222 #: ../../rst/dev_guide/testing_integration_legacy.rst:78 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:228 msgid "Network Tests" msgstr "ネットワークテスト" #: ../../rst/dev_guide/testing_integration.rst:230 msgid "For guidance on writing network test see :ref:`testing_resource_modules`." msgstr "ネットワークテストの書き込みに関する情報は、「:ref:`testing_resource_modules`」を参照してください。" #: ../../rst/dev_guide/testing_integration.rst:234 msgid "Where to find out more" msgstr "その他の詳細情報" #: ../../rst/dev_guide/testing_integration.rst:236 msgid "If you'd like to know more about the plans for improving testing Ansible, join the `Testing Working Group `_." msgstr "Ansible テストを改善する詳細な計画を確認したい場合は、`テストのワーキンググループ `_ にご参加ください。" #: ../../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 leverage 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 `_ for information on creating a profile." msgstr "AWS テストによっては、環境変数を使用するものもあります。AWS 環境変数 (``AWS_DEFAULT_PROFILE``、``AWS_SECRET_ACCESS_KEY`` など) の設定を解除するか、環境変数が ``credentials.yml`` で提供される認証情報と一致することを確認して、予想されるアカウントの完全な機能に一貫性のあるテストが実行されるようにすることが推奨されます。プロファイルの作成に関する情報は、`AWS CLI ドキュメント `_ を参照してください。" #: ../../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 の ``test/integration/amazon.yml`` 不要なロール (例: 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:51 msgid "Other configuration" msgstr "その他の設定" #: ../../rst/dev_guide/testing_integration_legacy.rst:53 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:60 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:65 msgid "testing-iam-policy.json.j2" msgstr "testing-iam-policy.json.j2" #: ../../rst/dev_guide/testing_integration_legacy.rst:67 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:84 #: ../../rst/dev_guide/testing_units.rst:24 msgid "Running Tests" msgstr "テストの実行" #: ../../rst/dev_guide/testing_integration_legacy.rst:86 msgid "The tests are invoked via a ``Makefile``." msgstr "テストは ``Makefile`` 経由で呼び出されます。" #: ../../rst/dev_guide/testing_integration_legacy.rst:88 msgid "If you haven't already got Ansible available use the local checkout by doing::" msgstr "Ansible がまだ利用可能でない場合は、以下の方法でローカルチェックアウトを使用します。" #: ../../rst/dev_guide/testing_integration_legacy.rst:92 msgid "Run the tests by doing::" msgstr "以下を実行してテストを実行します。" #: ../../rst/dev_guide/testing_integration_legacy.rst:102 msgid "Possible cost of running cloud tests" msgstr "クラウドテストにかかる可能性のあるコスト" #: ../../rst/dev_guide/testing_integration_legacy.rst:104 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 `_ for additional details." msgstr "詳細は、「`サポート対象のプラットフォームおよびバージョンの一覧 `_」を参照してください。" #: ../../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 ` instructions." msgstr "例: ``ansible-test integration --venv`` の実行時に ``ANSIBLE_KEEP_REMOTE_FILES=1`` を設定できますが、``--docker`` オプションを使用すると、``ansible-test shell`` を実行し、Docker 環境へのアクセスが必要になります。シェルプロンプトでは、環境変数を設定してテストを行う可能性があります。これは、:ref:`Debugging AnsibleModule-based 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:81 #: ../../rst/dev_guide/testing_units.rst:191 msgid "Reports can be generated in several different formats:" msgstr "Report は、複数の形式で生成できます。" #: ../../rst/dev_guide/testing_running_locally.rst:83 #: ../../rst/dev_guide/testing_units.rst:193 msgid "``ansible-test coverage report`` - Console report." msgstr "``ansible-test coverage report`` - コンソールレポート。" #: ../../rst/dev_guide/testing_running_locally.rst:84 #: ../../rst/dev_guide/testing_units.rst:194 msgid "``ansible-test coverage html`` - HTML report." msgstr "``ansible-test coverage html`` - HTML レポート。" #: ../../rst/dev_guide/testing_running_locally.rst:85 #: ../../rst/dev_guide/testing_units.rst:195 msgid "``ansible-test coverage xml`` - XML report." msgstr "``ansible-test coverage xml`` - XML レポート。" #: ../../rst/dev_guide/testing_running_locally.rst:87 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 ``--docker-keep-git`` argument to avoid git related errors." msgstr "docker および ``--base-branch`` 引数を使用する場合は、git 関連のエラーを回避するために ``--docker-keep-git`` 引数も使用します。" #: ../../rst/dev_guide/testing_sanity.rst:49 #: ../../rst/dev_guide/testing_units.rst:17 msgid "Available Tests" msgstr "利用可能なテスト" #: ../../rst/dev_guide/testing_sanity.rst:51 msgid "Tests can be listed with ``ansible-test sanity --list-tests``." msgstr "テストは ``ansible-test sanity --list-tests`` で一覧表示できます。" #: ../../rst/dev_guide/testing_sanity.rst:53 msgid "See the full list of :ref:`sanity tests `, which details the various tests and details how to fix identified issues." msgstr "各種テストや特定された問題を解決する方法の詳細は、「:ref:`サニティーテスト `」の一覧を参照してください。" #: ../../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 `_. Notice that the directory structure of the tests matches that of ``lib/ansible/``." msgstr "ユニットテストは `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:60 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:68 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:70 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:78 msgid "The list of unit test requirements can be found at `test/units/requirements.txt `_." msgstr "ユニットテストの要件一覧は、`test/units/requirements.txt `_ を参照してください。" #: ../../rst/dev_guide/testing_units.rst:81 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 `_." msgstr "これには、``ansible-test`` のユニットテスト要件のリストは含まれていません。それは、`test/lib/ansible_test/_data/requirements/units.txt `_ で見つけることができます。" #: ../../rst/dev_guide/testing_units.rst:85 msgid "See also the `constraints `_ applicable to all test commands." msgstr "すべてのコマンドに適用可能な「`制約 `_」も参照してください。" #: ../../rst/dev_guide/testing_units.rst:91 msgid "Extending unit tests" msgstr "ユニットテストの拡張" #: ../../rst/dev_guide/testing_units.rst:94 msgid "What a unit test isn't" msgstr "ユニットテスト以外のもの" #: ../../rst/dev_guide/testing_units.rst:96 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:101 msgid "Structuring Unit Tests" msgstr "ユニットテストの構造" #: ../../rst/dev_guide/testing_units.rst:103 msgid "Ansible drives unit tests through `pytest `_. This means that tests can either be written a simple functions which are included in any file name like ``test_.py`` or as classes." msgstr "Ansible は、`pytest `_ でユニットテストを行います。これは、テストは、``test_.py`` のファイル名またはクラスとして含まれる単純な関数を記述できることを意味します。" #: ../../rst/dev_guide/testing_units.rst:107 msgid "Here is an example of a function::" msgstr "以下は、関数の例です。" #: ../../rst/dev_guide/testing_units.rst:117 msgid "Here is an example of a class::" msgstr "以下はクラスの例です::" #: ../../rst/dev_guide/testing_units.rst:137 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:143 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:148 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:154 msgid "Module test case common code" msgstr "それが直接インクルードされます。" #: ../../rst/dev_guide/testing_units.rst:156 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:159 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:164 msgid "Fixtures files" msgstr "Fixtures ファイル" #: ../../rst/dev_guide/testing_units.rst:166 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:169 msgid "You can check how `fixtures `_ are used in `cpuinfo fact tests `_" msgstr "`cpuinfo ファクトテスト `_ で、`修正 `_ が使用される方法を確認することができます。" #: ../../rst/dev_guide/testing_units.rst:172 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:177 msgid "Code Coverage For New or Updated Unit Tests" msgstr "新規ユニットテストまたは更新されたユニットテスト用のコード対応" #: ../../rst/dev_guide/testing_units.rst:178 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:182 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:189 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:197 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:204 msgid ":ref:`testing_units_modules`" msgstr ":ref:`testing_units_modules`" #: ../../rst/dev_guide/testing_units.rst:205 msgid "Special considerations for unit testing modules" msgstr "ユニットテストモジュールに関する特別な考慮事項" #: ../../rst/dev_guide/testing_units.rst:206 #: ../../rst/dev_guide/testing_units_modules.rst:543 msgid ":ref:`testing_running_locally`" msgstr ":ref:`testing_running_locally`" #: ../../rst/dev_guide/testing_units.rst:207 #: ../../rst/dev_guide/testing_units_modules.rst:544 msgid "Running tests locally including gathering and reporting coverage data" msgstr "カバレージデータの収集とレポートを含む、ローカルでのテストの実行" #: ../../rst/dev_guide/testing_units.rst:208 #: ../../rst/dev_guide/testing_units_modules.rst:547 msgid "`Python 3 documentation - 26.4. unittest — Unit testing framework `_" msgstr "`Python 3 documentation - 26.4. unittest — Unit testing framework `_" #: ../../rst/dev_guide/testing_units.rst:209 #: ../../rst/dev_guide/testing_units_modules.rst:548 msgid "The documentation of the unittest framework in python 3" msgstr "Python 3 におけるユニットテストフレームワークのドキュメント" #: ../../rst/dev_guide/testing_units.rst:210 #: ../../rst/dev_guide/testing_units_modules.rst:549 msgid "`Python 2 documentation - 25.3. unittest — Unit testing framework `_" msgstr "`Python 2 documentation - 25.3. unittest — Unit testing framework `_" #: ../../rst/dev_guide/testing_units.rst:211 #: ../../rst/dev_guide/testing_units_modules.rst:550 msgid "The documentation of the earliest supported unittest framework - from Python 2.6" msgstr "サポートされている初期のユニットテストフレームワークのドキュメント (Python 2.6)" #: ../../rst/dev_guide/testing_units.rst:212 #: ../../rst/dev_guide/testing_units_modules.rst:551 msgid "`pytest: helps you write better programs `_" msgstr "`pytest: helps you write better programs `_" #: ../../rst/dev_guide/testing_units.rst:213 #: ../../rst/dev_guide/testing_units_modules.rst:552 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 Ansible IRC." msgstr "このドキュメントでは、Ansible モジュールにユニットテストを使用する理由、方法、タイミングについて説明します。このドキュメントは、通常 Python の標準に近い推奨事項を持つA nsible の他の部分には適用されません。AnAnsible のユニットテストに関する基本的なドキュメントは、開発者ガイドの「:ref:`testing_units`」にあります。このドキュメントは、新しい Ansible モジュールの作成者にとって読みやすいものでなければなりません。不完全だったり、分かりにくかったりした場合は、バグを報告したり、Ansible 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 Shippable." msgstr "Shippable で実行されているメインの 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:177 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:182 msgid "Mocking of the actual module" msgstr "実際のモジュールのモック化" #: ../../rst/dev_guide/testing_units_modules.rst:184 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 "実際のモジュールの設定は非常に複雑で (以下の `Passing Arguments`_ を参照)、モジュールを使用するほとんどの機能には必要ありません。モックオブジェクトをモジュールとして使用する代わりに、テストする関数で必要なモジュール属性を作成できます。この場合、モジュールの終了関数は、上述のように、例外を発生させるか、呼び出されていないことを確認するなど、特別な処理が必要になることに注意してください。以下に例を示します。" #: ../../rst/dev_guide/testing_units_modules.rst:203 msgid "API definition with unit test cases" msgstr "ユニットテストケースでの API 定義" #: ../../rst/dev_guide/testing_units_modules.rst:205 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:210 msgid "Defining a module against an API specification" msgstr "API の仕様に対してモジュールを定義" #: ../../rst/dev_guide/testing_units_modules.rst:212 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:215 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:221 msgid "*Example: in rds_instance unit tests a simple instance state is defined*::" msgstr "*例: rds_instance ユニットテストでは、単純なインスタンスの状態が定義されています*::" #: ../../rst/dev_guide/testing_units_modules.rst:229 msgid "This is then used to create a list of states::" msgstr "次に、これを使用して状態のリストを作成します。" #: ../../rst/dev_guide/testing_units_modules.rst:244 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:252 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:257 msgid "Defining a module to work against multiple API versions" msgstr "複数の API バージョンに対して動作するモジュールの定義" #: ../../rst/dev_guide/testing_units_modules.rst:259 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:263 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:268 msgid "Ansible special cases for unit testing" msgstr "Ansible ユニットテストの特殊なケース" #: ../../rst/dev_guide/testing_units_modules.rst:270 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 IRC channel or mailing lists." msgstr "Ansible モジュールの環境に対してユニットテストを行うための特別なケースがいくつかあります。最も一般的なものを以下に示します。他の人への提案は、既存のユニットテストのソースコードを確認するか、Ansible IRC チャンネルまたはメーリングリストで質問することで見つけることができます。" #: ../../rst/dev_guide/testing_units_modules.rst:276 msgid "Module argument processing" msgstr "モジュール引数処理" #: ../../rst/dev_guide/testing_units_modules.rst:278 msgid "There are two problems with running the main function of a module:" msgstr "モジュールの主な関数の実行には、以下の 2 つの問題があります。" #: ../../rst/dev_guide/testing_units_modules.rst:280 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:282 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:286 msgid "Passing Arguments" msgstr "引数の渡し方" #: ../../rst/dev_guide/testing_units_modules.rst:291 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:309 msgid "Handling exit correctly" msgstr "終了を適切に処理" #: ../../rst/dev_guide/testing_units_modules.rst:314 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:324 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:337 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:342 msgid "Running the main function" msgstr "主な関数の実行" #: ../../rst/dev_guide/testing_units_modules.rst:344 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:362 msgid "Handling calls to external executables" msgstr "外部実行ファイルへの呼び出しの処理" #: ../../rst/dev_guide/testing_units_modules.rst:364 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:367 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:381 msgid "A Complete Example" msgstr "完全な例" #: ../../rst/dev_guide/testing_units_modules.rst:383 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:469 msgid "Restructuring modules to enable testing module set up and other processes" msgstr "テストモジュールの設定などを可能にするためのモジュールの再構築" #: ../../rst/dev_guide/testing_units_modules.rst:471 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:501 msgid "This now makes it possible to run tests against the module initiation function::" msgstr "これにより、モジュールの開始関数に対してテストを実行できるようになりました。" #: ../../rst/dev_guide/testing_units_modules.rst:513 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:515 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:519 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:522 msgid "Traps for maintaining Python 2 compatibility" msgstr "Python 2 の互換性を維持するためのトラップ" #: ../../rst/dev_guide/testing_units_modules.rst:524 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:529 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:533 msgid "Maintain Python 2.6 compatibility" msgstr "Python 2.6 互換性の維持" #: ../../rst/dev_guide/testing_units_modules.rst:535 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:542 msgid "Ansible unit tests documentation" msgstr "Ansible unit テストドキュメント" #: ../../rst/dev_guide/testing_units_modules.rst:546 msgid "Get started developing a module" msgstr "モジュール開発を始める" #: ../../rst/dev_guide/testing_units_modules.rst:555 msgid "`Testing Your Code (from The Hitchhiker's Guide to Python!) `_" msgstr "`Testing Your Code (from The Hitchhiker's Guide to Python!) `_" #: ../../rst/dev_guide/testing_units_modules.rst:556 msgid "General advice on testing Python code" msgstr "Python コードのテストに関する一般的なアドバイス" #: ../../rst/dev_guide/testing_units_modules.rst:558 msgid "`Uncle Bob's many videos on YouTube `_" msgstr "`Uncle Bob's many videos on YouTube `_" #: ../../rst/dev_guide/testing_units_modules.rst:558 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:560 msgid "`\"Why Most Unit Testing is Waste\" `_" msgstr "`\"Why Most Unit Testing is Waste\" `_" #: ../../rst/dev_guide/testing_units_modules.rst:561 msgid "An article warning against the costs of unit testing" msgstr "ユニットテストの大半が無駄である理由" #: ../../rst/dev_guide/testing_units_modules.rst:562 msgid "`'A Response to \"Why Most Unit Testing is Waste\"' `_" msgstr "`'A Response to \"Why Most Unit Testing is Waste\"' `_" #: ../../rst/dev_guide/testing_units_modules.rst:563 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 "本プログラムは、元々 Michay 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 `_ that is used to validate the YAML blocks, such as ``DOCUMENTATION`` and ``RETURNS``." msgstr "``validate-modules`` ツールには、``DOCUMENTATION``、``RETURNS`` などの YAML ブロックの検証に使用される `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-version" msgstr "ansible-deprecated-version" #: ../../rst/dev_guide/testing_validate-modules.rst:64 #: ../../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:82 #: ../../rst/dev_guide/testing_validate-modules.rst:85 #: ../../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:94 #: ../../rst/dev_guide/testing_validate-modules.rst:95 #: ../../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:101 #: ../../rst/dev_guide/testing_validate-modules.rst:102 #: ../../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:114 #: ../../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: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:84 #: ../../rst/dev_guide/testing_validate-modules.rst:85 #: ../../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: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: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:110 #: ../../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 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:65 msgid "ansible-module-not-initialized" msgstr "ansible-module-not-initialized" #: ../../rst/dev_guide/testing_validate-modules.rst:65 #: ../../rst/dev_guide/testing_validate-modules.rst:97 #: ../../rst/dev_guide/testing_validate-modules.rst:103 #: ../../rst/dev_guide/testing_validate-modules.rst:104 #: ../../rst/dev_guide/testing_validate-modules.rst:107 #: ../../rst/dev_guide/testing_validate-modules.rst:109 #: ../../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:65 msgid "Execution of the module did not result in initialization of AnsibleModule" msgstr "モジュールを実行しても、AnsibleModule は初期化されなかった。" #: ../../rst/dev_guide/testing_validate-modules.rst:66 msgid "collection-deprecated-version" msgstr "collection-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 collection version" msgstr "機能は非推奨となり、現行またはそれ以前のバージョンのコレクションで削除される予定です。" #: ../../rst/dev_guide/testing_validate-modules.rst:67 msgid "deprecated-date" msgstr "deprecated-date" #: ../../rst/dev_guide/testing_validate-modules.rst:67 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:68 msgid "deprecation-mismatch" msgstr "deprecation-mismatch" #: ../../rst/dev_guide/testing_validate-modules.rst:68 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 "ファイル名、そのメタデータの少なくとも 1 つ、または DOCUMENTATION (非推奨の場合は DOCUMENTATION.deprecated を設定するか、削除の場合はすべてのドキュメントを削除する) で非推奨または削除済みとしてマークされたモジュールですが、3 カ所すべてではありません。" #: ../../rst/dev_guide/testing_validate-modules.rst:69 msgid "doc-choices-do-not-match-spec" msgstr "doc-choices-do-not-match-spec" #: ../../rst/dev_guide/testing_validate-modules.rst:69 msgid "Value for \"choices\" from the argument_spec does not match the documentation" msgstr "argument_spec の「choices」の値がドキュメントと一致しない。" #: ../../rst/dev_guide/testing_validate-modules.rst:70 msgid "doc-choices-incompatible-type" msgstr "doc-choices-incompatible-type" #: ../../rst/dev_guide/testing_validate-modules.rst:70 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:71 msgid "doc-default-does-not-match-spec" msgstr "doc-default-does-not-match-spec" #: ../../rst/dev_guide/testing_validate-modules.rst:71 msgid "Value for \"default\" from the argument_spec does not match the documentation" msgstr "argument_spec の「default」の値がドキュメントと一致しない。" #: ../../rst/dev_guide/testing_validate-modules.rst:72 msgid "doc-default-incompatible-type" msgstr "doc-default-incompatible-type" #: ../../rst/dev_guide/testing_validate-modules.rst:72 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:73 msgid "doc-elements-invalid" msgstr "doc-elements-invalid" #: ../../rst/dev_guide/testing_validate-modules.rst:73 msgid "Documentation specifies elements for argument, when \"type\" is not ``list``." msgstr "ドキュメントでは、「type」が ``list`` ではない場合に、引数の要素を指定します。" #: ../../rst/dev_guide/testing_validate-modules.rst:74 msgid "doc-elements-mismatch" msgstr "doc-elements-mismatch" #: ../../rst/dev_guide/testing_validate-modules.rst:74 msgid "Argument_spec defines elements different than documentation does" msgstr "Argument_spec はドキュメントとは異なるタイプを定義する。" #: ../../rst/dev_guide/testing_validate-modules.rst:75 msgid "doc-missing-type" msgstr "doc-missing-type" #: ../../rst/dev_guide/testing_validate-modules.rst:75 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:76 msgid "doc-required-mismatch" msgstr "doc-required-mismatch" #: ../../rst/dev_guide/testing_validate-modules.rst:76 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:77 msgid "doc-type-does-not-match-spec" msgstr "doc-type-does-not-match-spec" #: ../../rst/dev_guide/testing_validate-modules.rst:77 msgid "Argument_spec defines type different than documentation does" msgstr "Argument_spec はドキュメントとは異なるタイプを定義" #: ../../rst/dev_guide/testing_validate-modules.rst:78 msgid "documentation-error" msgstr "documentation-error" #: ../../rst/dev_guide/testing_validate-modules.rst:78 msgid "Unknown ``DOCUMENTATION`` error" msgstr "不明な ``DOCUMENTATION`` エラー" #: ../../rst/dev_guide/testing_validate-modules.rst:79 msgid "documentation-syntax-error" msgstr "documentation-syntax-error" #: ../../rst/dev_guide/testing_validate-modules.rst:79 msgid "Invalid ``DOCUMENTATION`` schema" msgstr "無効な ``DOCUMENTATION`` スキーマ" #: ../../rst/dev_guide/testing_validate-modules.rst:80 msgid "illegal-future-imports" msgstr "illegal-future-imports" #: ../../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:105 #: ../../rst/dev_guide/testing_validate-modules.rst:106 #: ../../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: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 "Import" #: ../../rst/dev_guide/testing_validate-modules.rst:80 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:81 msgid "import-before-documentation" msgstr "import-before-documentation" #: ../../rst/dev_guide/testing_validate-modules.rst:81 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:82 msgid "import-error" msgstr "import-error" #: ../../rst/dev_guide/testing_validate-modules.rst:82 msgid "``Exception`` attempting to import module for ``argument_spec`` introspection" msgstr "``Exception`` が、``argument_spec`` イントロスペクションのモジュールのインポートを試行中" #: ../../rst/dev_guide/testing_validate-modules.rst:83 msgid "import-placement" msgstr "import-placement" #: ../../rst/dev_guide/testing_validate-modules.rst:83 msgid "Locations" msgstr "場所" #: ../../rst/dev_guide/testing_validate-modules.rst:83 #: ../../rst/dev_guide/testing_validate-modules.rst:99 #: ../../rst/dev_guide/testing_validate-modules.rst:105 #: ../../rst/dev_guide/testing_validate-modules.rst:111 #: ../../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:83 #: ../../rst/dev_guide/testing_validate-modules.rst:84 msgid "Imports should be directly below ``DOCUMENTATION``/``EXAMPLES``/``RETURN``" msgstr "インポートは、``DOCUMENTATION``/``EXAMPLES``/``RETURN`` のすぐ後に配置しなければなりません。" #: ../../rst/dev_guide/testing_validate-modules.rst:84 msgid "imports-improper-location" msgstr "imports-improper-location" #: ../../rst/dev_guide/testing_validate-modules.rst:85 msgid "incompatible-choices" msgstr "incompatible-choices" #: ../../rst/dev_guide/testing_validate-modules.rst:85 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:86 msgid "incompatible-default-type" msgstr "incompatible-default-type" #: ../../rst/dev_guide/testing_validate-modules.rst:86 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:87 msgid "invalid-argument-name" msgstr "invalid-argument-name" #: ../../rst/dev_guide/testing_validate-modules.rst:87 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:88 msgid "invalid-argument-spec" msgstr "invalid-argument-spec" #: ../../rst/dev_guide/testing_validate-modules.rst:88 msgid "Argument in argument_spec must be a dictionary/hash when used" msgstr "argument_spec の引数を使用する場合は、ディクショナリーまたはハッシュである必要がある。" #: ../../rst/dev_guide/testing_validate-modules.rst:89 msgid "invalid-argument-spec-options" msgstr "invalid-argument-spec-options" #: ../../rst/dev_guide/testing_validate-modules.rst:89 msgid "Suboptions in argument_spec are invalid" msgstr "argument_spec のサブオプションは無効" #: ../../rst/dev_guide/testing_validate-modules.rst:90 msgid "invalid-documentation" msgstr "invalid-documentation" #: ../../rst/dev_guide/testing_validate-modules.rst:90 msgid "``DOCUMENTATION`` is not valid YAML" msgstr "``DOCUMENTATION`` は、有効な YAML ではありません" #: ../../rst/dev_guide/testing_validate-modules.rst:91 msgid "invalid-documentation-options" msgstr "invalid-documentation-options" #: ../../rst/dev_guide/testing_validate-modules.rst:91 msgid "``DOCUMENTATION.options`` must be a dictionary/hash when used" msgstr "``DOCUMENTATION.options`` 使用する場合は、ディクショナリー/ハッシュでなければなりません" #: ../../rst/dev_guide/testing_validate-modules.rst:92 msgid "invalid-examples" msgstr "invalid-examples" #: ../../rst/dev_guide/testing_validate-modules.rst:92 msgid "``EXAMPLES`` is not valid YAML" msgstr "``EXAMPLES`` は、有効な YAML ではありません" #: ../../rst/dev_guide/testing_validate-modules.rst:93 msgid "invalid-extension" msgstr "invalid-extension" #: ../../rst/dev_guide/testing_validate-modules.rst:93 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:94 msgid "invalid-module-schema" msgstr "invalid-module-schema" #: ../../rst/dev_guide/testing_validate-modules.rst:94 msgid "``AnsibleModule`` schema validation error" msgstr "``AnsibleModule`` スキーマ検証エラー" #: ../../rst/dev_guide/testing_validate-modules.rst:95 msgid "invalid-removal-version" msgstr "invalid-removal-version" #: ../../rst/dev_guide/testing_validate-modules.rst:95 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:96 msgid "invalid-requires-extension" msgstr "invalid-requires-extension" #: ../../rst/dev_guide/testing_validate-modules.rst:96 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:97 msgid "last-line-main-call" msgstr "last-line-main-call" #: ../../rst/dev_guide/testing_validate-modules.rst:97 msgid "Call to ``main()`` not the last line (or ``removed_module()`` in the case of deprecated & docs only modules)" msgstr "最終行以外の ``main()`` の呼出し (または、非推奨およびドキュメントのみのモジュールでは ``removed_module()``)。" #: ../../rst/dev_guide/testing_validate-modules.rst:98 msgid "missing-doc-fragment" msgstr "missing-doc-fragment" #: ../../rst/dev_guide/testing_validate-modules.rst:98 msgid "``DOCUMENTATION`` fragment missing" msgstr "``DOCUMENTATION`` フラグメントがない" #: ../../rst/dev_guide/testing_validate-modules.rst:99 msgid "missing-existing-doc-fragment" msgstr "missing-existing-doc-fragment" #: ../../rst/dev_guide/testing_validate-modules.rst:99 msgid "Pre-existing ``DOCUMENTATION`` fragment missing" msgstr "既存の ``DOCUMENTATION`` フラグメントがない" #: ../../rst/dev_guide/testing_validate-modules.rst:100 msgid "missing-documentation" msgstr "missing-documentation" #: ../../rst/dev_guide/testing_validate-modules.rst:100 msgid "No ``DOCUMENTATION`` provided" msgstr "``DOCUMENTATION`` が提供されていない" #: ../../rst/dev_guide/testing_validate-modules.rst:101 msgid "missing-examples" msgstr "missing-examples" #: ../../rst/dev_guide/testing_validate-modules.rst:101 msgid "No ``EXAMPLES`` provided" msgstr "``EXAMPLES`` が提供されていない" #: ../../rst/dev_guide/testing_validate-modules.rst:102 msgid "missing-gplv3-license" msgstr "missing-gplv3-license" #: ../../rst/dev_guide/testing_validate-modules.rst:102 msgid "GPLv3 license header not found" msgstr "GPLv3 ライセンスヘッダーが見つからない" #: ../../rst/dev_guide/testing_validate-modules.rst:103 msgid "missing-if-name-main" msgstr "missing-if-name-main" #: ../../rst/dev_guide/testing_validate-modules.rst:103 msgid "Next to last line is not ``if __name__ == \"__main__\":``" msgstr "最後の行の隣になるものは、``if __name__ == \"__main__\":`` ではない" #: ../../rst/dev_guide/testing_validate-modules.rst:104 msgid "missing-main-call" msgstr "missing-main-call" #: ../../rst/dev_guide/testing_validate-modules.rst:104 msgid "Did not find a call to ``main()`` (or ``removed_module()`` in the case of deprecated & docs only modules)" msgstr "``main()`` への呼出しが見つからなかった (非推奨またはドキュメントのみのモジュールの場合は ``removed_module()``)。" #: ../../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 util 要件/インポートがある" #: ../../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-doc" msgstr "missing-python-doc" #: ../../rst/dev_guide/testing_validate-modules.rst:108 msgid "Missing python documentation file" msgstr "python ドキュメントファイルがありません" #: ../../rst/dev_guide/testing_validate-modules.rst:109 msgid "missing-python-interpreter" msgstr "missing-python-interpreter" #: ../../rst/dev_guide/testing_validate-modules.rst:109 msgid "Interpreter line is not ``#!/usr/bin/python``" msgstr "インタープリター行、``#!/usr/bin/python`` ではありません。" #: ../../rst/dev_guide/testing_validate-modules.rst:110 msgid "missing-return" msgstr "missing-return" #: ../../rst/dev_guide/testing_validate-modules.rst:110 msgid "No ``RETURN`` documentation provided" msgstr "``RETURN`` のドキュメントは提供されていません" #: ../../rst/dev_guide/testing_validate-modules.rst:111 msgid "missing-return-legacy" msgstr "missing-return-legacy" #: ../../rst/dev_guide/testing_validate-modules.rst:111 msgid "No ``RETURN`` documentation provided for legacy module" msgstr "レガシーモジュールには ``RETURN`` のドキュメントがありません" #: ../../rst/dev_guide/testing_validate-modules.rst:112 msgid "missing-suboption-docs" msgstr "missing-suboption-docs" #: ../../rst/dev_guide/testing_validate-modules.rst:112 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:113 msgid "module-incorrect-version-added" msgstr "module-incorrect-version-added" #: ../../rst/dev_guide/testing_validate-modules.rst:113 msgid "Module level ``version_added`` is incorrect" msgstr "モジュールレベル ``version_added`` は正しくありません" #: ../../rst/dev_guide/testing_validate-modules.rst:114 msgid "module-invalid-version-added" msgstr "module-invalid-version-added" #: ../../rst/dev_guide/testing_validate-modules.rst:114 msgid "Module level ``version_added`` is not a valid version number" msgstr "モジュールレベルの ``version_added`` は、有効なバージョン番号ではありません" #: ../../rst/dev_guide/testing_validate-modules.rst:115 msgid "module-utils-specific-import" msgstr "module-utils-specific-import" #: ../../rst/dev_guide/testing_validate-modules.rst:115 msgid "``module_utils`` imports should import specific components, not ``*``" msgstr "``module_utils`` は、``*`` ではなく、特定のコンポーネントをインポートする必要があります。" #: ../../rst/dev_guide/testing_validate-modules.rst:116 msgid "multiple-utils-per-requires" msgstr "multiple-utils-per-requires" #: ../../rst/dev_guide/testing_validate-modules.rst:116 msgid "``Ansible.ModuleUtils`` requirements do not support multiple modules per statement" msgstr "``Ansible.ModuleUtils`` 要件は、ステートメントごとに複数のモジュールをサポートしません。" #: ../../rst/dev_guide/testing_validate-modules.rst:117 msgid "multiple-csharp-utils-per-requires" msgstr "multiple-csharp-utils-per-requires" #: ../../rst/dev_guide/testing_validate-modules.rst:117 msgid "Ansible C# util requirements do not support multiple utils per statement" msgstr "C# ユーティリティー要件は、ステートメントごとに複数のモジュールをサポートしません。" #: ../../rst/dev_guide/testing_validate-modules.rst:118 msgid "no-default-for-required-parameter" msgstr "no-default-for-required-parameter" #: ../../rst/dev_guide/testing_validate-modules.rst:118 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: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 #: ../../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: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 ` for new modules" msgstr "GPLv3 ライセンスヘッダーは、新しいモジュールの :ref:`短縮形 ` である必要があります" #: ../../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 ""