# This file is distributed under the same license as the Ansible package.
# FIRST AUTHOR <EMAIL@ADDRESS>, 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: Ansible devel\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-02-23 10:50+0100\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Generated-By: Babel 2.9.0\n"
#: ../../rst/community/code_of_conduct.rst:5
msgid "Community Code of Conduct"
msgstr "コミュニティーの行動規範"
#: ../../rst/community/code_of_conduct.rst:7
#: ../../rst/community/github_admins.rst:7
#: ../../rst/community/release_managers.rst:7
msgid "Topics"
msgstr "トピック"
#: ../../rst/community/code_of_conduct.rst:9
msgid "Every community can be strengthened by a diverse variety of viewpoints, insights, opinions, skillsets, and skill levels. However, with diversity comes the potential for disagreement and miscommunication. The purpose of this Code of Conduct is to ensure that disagreements and differences of opinion are conducted respectfully and on their own merits, without personal attacks or other behavior that might create an unsafe or unwelcoming environment."
msgid "These policies are not designed to be a comprehensive set of Things You Cannot Do. We ask that you treat your fellow community members with respect and courtesy, and in general, Don't Be A Jerk. This Code of Conduct is meant to be followed in spirit as much as in letter and is not exhaustive."
msgid "All Ansible events and participants therein are governed by this Code of Conduct and anti-harassment policy. We expect organizers to enforce these guidelines throughout all events, and we expect attendees, speakers, sponsors, and volunteers to help ensure a safe environment for our whole community. Specifically, this Code of Conduct covers participation in all Ansible-related forums and mailing lists, code and documentation contributions, public IRC channels, private correspondence, and public meetings."
msgid "Contributions of every kind have far-ranging consequences. Just as your work depends on the work of others, decisions you make surrounding your contributions to the Ansible community will affect your fellow community members. You are strongly encouraged to take those consequences into account while making decisions."
msgid "Asynchronous communication can come with its own frustrations, even in the most responsive of communities. Please remember that our community is largely built on volunteered time, and that questions, contributions, and requests for support may take some time to receive a response. Repeated \"bumps\" or \"reminders\" in rapid succession are not good displays of patience. Additionally, it is considered poor manners to ping a specific person with general questions. Pose your question to the community as a whole, and wait patiently for a response."
msgid "Every community inevitably has disagreements, but remember that it is possible to disagree respectfully and courteously. Disagreements are never an excuse for rudeness, hostility, threatening behavior, abuse (verbal or physical), or personal attacks."
msgid "Everyone should feel welcome in the Ansible community, regardless of their background. Please be courteous, respectful and polite to fellow community members. Do not make or post offensive comments related to skill level, gender, gender identity or expression, sexual orientation, disability, physical appearance, body size, race, or religion. Sexualized images or imagery, real or implied violence, intimidation, oppression, stalking, sustained disruption of activities, publishing the personal information of others without explicit permission to do so, unwanted physical contact, and unwelcome sexual attention are all strictly prohibited. Additionally, you are encouraged not to make assumptions about the background or identity of your fellow community members."
msgid "The only stupid question is the one that does not get asked. We encourage our users to ask early and ask often. Rather than asking whether you can ask a question (the answer is always yes!), instead, simply ask your question. You are encouraged to provide as many specifics as possible. Code snippets in the form of Gists or other paste site links are almost always needed in order to get the most helpful answers. Refrain from pasting multiple lines of code directly into the IRC channels - instead use gist.github.com or another paste site to provide code snippets."
msgid "The Ansible community is committed to being a welcoming environment for all users, regardless of skill level. We were all beginners once upon a time, and our community cannot grow without an environment where new users feel safe and comfortable asking questions. It can become frustrating to answer the same questions repeatedly; however, community members are expected to remain courteous and helpful to all users equally, regardless of skill or knowledge level. Avoid providing responses that prioritize snideness and snark over useful information. At the same time, everyone is expected to read the provided documentation thoroughly. We are happy to answer questions, provide strategic guidance, and suggest effective workflows, but we are not here to do your job for you."
msgid "Offensive comments related to gender (including gender expression and identity), age, sexual orientation, disability, physical appearance, body size, race, and religion"
msgid "Derogatory terminology including words commonly known to be slurs"
msgstr "一般的に中傷であると知られている言葉を含む中傷的な用語"
#: ../../rst/community/code_of_conduct.rst:94
msgid "Posting sexualized images or imagery in public spaces"
msgstr "公共の場に性的な画像を投稿すること"
#: ../../rst/community/code_of_conduct.rst:95
msgid "Deliberate intimidation"
msgstr "意図的な脅迫"
#: ../../rst/community/code_of_conduct.rst:96
msgid "Stalking"
msgstr "ストーカー行為"
#: ../../rst/community/code_of_conduct.rst:97
msgid "Posting others' personal information without explicit permission"
msgstr "明示的な許可なく他のユーザーの個人情報を投稿すること"
#: ../../rst/community/code_of_conduct.rst:98
msgid "Sustained disruption of talks or other events"
msgstr "会話やその他のイベントの継続的な中断"
#: ../../rst/community/code_of_conduct.rst:99
msgid "Inappropriate physical contact"
msgstr "不適切な身体的接触"
#: ../../rst/community/code_of_conduct.rst:100
msgid "Unwelcome sexual attention"
msgstr "歓迎されない性的注目"
#: ../../rst/community/code_of_conduct.rst:102
msgid "Participants asked to stop any harassing behavior are expected to comply immediately. Sponsors are also subject to the anti-harassment policy. In particular, sponsors should not use sexualized images, activities, or other material. Meetup organizing staff and other volunteer organizers should not use sexualized attire or otherwise create a sexualized environment at community events."
msgid "In addition to the behaviors outlined above, continuing to behave a certain way after you have been asked to stop also constitutes harassment, even if that behavior is not specifically outlined in this policy. It is considerate and respectful to stop doing something after you have been asked to stop, and all community members are expected to comply with such requests immediately."
msgid "Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting `codeofconduct@ansible.com <mailto:codeofconduct@ansible.com>`_, to any channel operator in the community IRC channels, or to the local organizers of an event. Meetup organizers are encouraged to prominently display points of contact for reporting unacceptable behavior at local events."
msgid "If a participant engages in harassing behavior, the meetup organizers may take any action they deem appropriate. These actions may include but are not limited to warning the offender, expelling the offender from the event, and barring the offender from future community events."
msgid "Organizers will be happy to help participants contact security or local law enforcement, provide escorts to an alternate location, or otherwise assist those experiencing harassment to feel safe for the duration of the meetup. We value the safety and well-being of our community members and want everyone to feel welcome at our events, both online and offline."
msgid "We expect all participants, organizers, speakers, and attendees to follow these policies at all of our event venues and event-related social events."
msgid "The Ansible Community Code of Conduct is licensed under the Creative Commons Attribution-Share Alike 3.0 license. Our Code of Conduct was adapted from Codes of Conduct of other open source projects, including:"
msgid "These are the guidelines for people with commit privileges on the Ansible GitHub repository. Committers are essentially acting as members of the Ansible Core team, although not necessarily as employees of Ansible and Red Hat. Please read the guidelines before you commit."
msgstr "このページは、Ansible GitHub リポジトリー上でコミット権限を持つユーザーのためのガイドラインです。コミット担当者は、基本的に Ansible Core チームのメンバーとして活動していますが、Ansible および Red Hat の従業員であるとは限りません。コミットする前にこのガイドラインをお読みください。"
#: ../../rst/community/committer_guidelines.rst:9
msgid "These guidelines apply to everyone. At the same time, this ISN'T a process document. So just use good judgment. You've been given commit access because we trust your judgment."
msgid "If you abuse the trust and break components and builds, and so on, the trust level falls and you may be asked not to commit or you may lose your commit privileges."
msgid "As a core team member, you are an integral part of the team that develops the :ref:`roadmap <roadmaps>`. Please be engaged, and push for the features and fixes that you want to see. Also keep in mind that Red Hat, as a company, will commit to certain features, fixes, APIs, and so on, for various releases. Red Hat, the company, and the Ansible team must get these changes completed and released as scheduled. Obligations to users, the community, and customers must come first. Because of these commitments, a feature you want to develop yourself may not get into a release if it affects a lot of other parts within Ansible."
msgstr "コミット担当者は、コアチームメンバーとして、:ref:`ロードマップ <roadmaps>` を作成するチームに不可欠です。積極的に関与し、希望する機能や修正をプッシュしてください。また、Red Hat は企業として、様々なリリースに対して、特定の機能、修正、API などにコミットすることを念頭に置いてください。企業である Red Hat、および Ansible チームは、このようなコミットされた機能 (など) を完成させ、スケジュール通りにリリースしなければなりません。ユーザー、コミュニティー、顧客への義務が最優先されなければなりません。これらの義務があるため、自分で開発したい機能が Ansible 内の他の多くの部分に影響を与える場合は、その機能がリリースに含まれない可能性があります。"
msgid "Any other new features and changes to high level design should go through the proposal process (TBD), to ensure the community and core team have had a chance to review the idea and approve it. The core team has sole responsibility for merging new features based on proposals."
msgid "As a committer, you may already know this, but our workflow forms a lot of our team policies. Please ensure you're aware of the following workflow steps:"
msgid "Create a Pull Request back to the Ansible repository and tag the people you would like to review; assign someone as the primary \"owner\" of your request"
msgid "The Core Team is aware that this can be a difficult process at times. Sometimes, the team breaks the rules by making direct commits or merging their own PRs. This section is a set of guidelines. If you're changing a comma in a doc, or making a very minor change, you can use your best judgement. This is another trust thing. The process is critical for any major change, but for little things or getting something done quickly, use your best judgement and make sure people on the team are aware of your work."
msgid ":ref:`Module maintainers <maintainers>`: Module maintainers own specific modules and have indirect commit access through the current module PR mechanisms."
msgid "Individuals with direct commit access to ansible/ansible are entrusted with powers that allow them to do a broad variety of things--probably more than we can write down. Rather than rules, treat these as general *guidelines*, individuals with this power are expected to use their best judgement."
msgid "Merge your own PRs. Someone else should have a chance to review and approve the PR merge. If you are a Core Committer, you have a small amount of leeway here for very minor changes."
msgid "Drag your community team members down. Always discuss the technical merits, but you should never address the person's limitations (you can later go for beers and call them idiots, but not in IRC/GitHub/and so on)."
msgid "Forget about the maintenance burden. Some things are really cool to have, but they might not be worth shoehorning in if the maintenance burden is too great."
msgid "Write tests. PRs with tests are looked at with more priority than PRs without tests that should have them included. While not all changes require tests, be sure to add them for bug fixes or functionality changes."
msgid "Document! If your PR is a new feature or a change to behavior, make sure you've updated all associated documentation or have notified the right people to do so. It also helps to add the version of ``ansible-base`` against which this documentation is compatible (to avoid confusion between stable and devel docs, for backwards compatibility, and so on)."
msgid "Individuals who've been asked to become a part of this group have generally been contributing in significant ways to the Ansible community for some time. Should they agree, they are requested to add their names and GitHub IDs to this file, in the section below, through a pull request. Doing so indicates that these individuals agree to act in the ways that their fellow committers trust that they will act."
msgstr "このグループの一員になることを尋ねられるユーザーは、通常、しばらくの間 Ansible コミュニティーに重要な貢献をしてきたユーザーです。同意したユーザーは、以下のセクションにあるこのファイルに名前と GitHub ID をプル要求で追加してください。この操作は、その他のコミット担当者に信頼してもらえる行動をとることに同意していることを示します。"
msgid "Please read and understand the :ref:`code_of_conduct`."
msgstr "「:ref:`code_of_conduct`」を読んで理解してください。"
#: ../../rst/community/communication.rst:16
msgid "Mailing list information"
msgstr "メーリングリストの情報"
#: ../../rst/community/communication.rst:18
msgid "Ansible has several mailing lists. Your first post to the mailing list will be moderated (to reduce spam), so please allow up to a day or so for your first post to appear."
msgid "`Ansible Announce list <https://groups.google.com/forum/#!forum/ansible-announce>`_ is a read-only list that shares information about new releases of Ansible, and also rare infrequent event information, such as announcements about an upcoming AnsibleFest, which is our official conference series. Worth subscribing to!"
msgstr "`Ansible Announce list <https://groups.google.com/forum/#!forum/ansible-announce>`_ は、Ansible の新規リリースに関する情報を共有する読み取り専用リストです。Ansible の公式カンファレンスシリーズである AnsibleFest に関するアナウンスなど、不定期に開催されるイベント情報を共有しているため、ぜひサブスクライブしてください。"
#: ../../rst/community/communication.rst:21
msgid "`Ansible AWX List <https://groups.google.com/forum/#!forum/awx-project>`_ is for `Ansible AWX <https://github.com/ansible/awx>`_ the upstream version of `Red Hat Ansible Tower <https://www.ansible.com/products/tower>`_"
msgstr "`Ansible AWX List <https://groups.google.com/forum/#!forum/awx-project>`_ は、`Red Hat Ansible Tower <https://www.ansible.com/products/tower>`_ のアップストリームバージョンである `Ansible AWX <https://github.com/ansible/awx>`_ です。"
#: ../../rst/community/communication.rst:22
msgid "`Ansible Container List <https://groups.google.com/forum/#!forum/ansible-container>`_ is for users and developers of the Ansible Container project."
msgstr "`Ansible Container List <https://groups.google.com/forum/#!forum/ansible-container>`_ は、Ansible Container プロジェクトのユーザーおよび開発者向けです。"
#: ../../rst/community/communication.rst:23
msgid "`Ansible Development List <https://groups.google.com/forum/#!forum/ansible-devel>`_ is for learning how to develop on Ansible, asking about prospective feature design, or discussions about extending ansible or features in progress."
msgstr "`Ansible Development List <https://groups.google.com/forum/#!forum/ansible-devel>`_ は、Ansible での開発方法を学ぶため、将来の機能設計について質問するため、あるいは進行中の Ansible または機能の拡張について議論するためのものです。"
#: ../../rst/community/communication.rst:24
msgid "`Ansible Lockdown List <https://groups.google.com/forum/#!forum/ansible-lockdown>`_ is for all things related to Ansible Lockdown projects, including DISA STIG automation and CIS Benchmarks."
msgid "`Ansible Outreach List <https://groups.google.com/forum/#!forum/ansible-outreach>`_ help with promoting Ansible and `Ansible Meetups <https://ansible.meetup.com/>`_"
msgid "`Ansible Project List <https://groups.google.com/forum/#!forum/ansible-project>`_ is for sharing Ansible tips, answering questions, and general user discussion."
msgstr "`Ansible Project List <https://groups.google.com/forum/#!forum/ansible-project>`_ は、Ansible のヒントを共有したり、質問に答えたり、一般的なユーザーディスカッションを行うためのものです。"
#: ../../rst/community/communication.rst:27
msgid "`Molecule Discussions <https://github.com/ansible-community/molecule/discussions>`_ is designed to aid with the development and testing of Ansible roles with Molecule."
msgid "To subscribe to a group from a non-Google account, you can send an email to the subscription address requesting the subscription. For example: ``ansible-devel+subscribe@googlegroups.com``"
msgid "Our IRC channels may require you to register your nickname. If you receive an error when you connect, see `Freenode's Nickname Registration guide <https://freenode.net/kb/answer/registration>`_ for instructions."
msgid "``#ansible-meeting`` - For public community meetings. We will generally announce these on one or more of the above mailing lists. See the `meeting schedule and agenda page <https://github.com/ansible/community/blob/main/meetings/README.md>`_"
msgid "Many of our community `Working Groups <https://github.com/ansible/community/wiki#working-groups>`_ meet on Freenode IRC channels. If you want to get involved in a working group, join the channel where it meets or comment on the agenda."
msgid "`Amazon (AWS) Working Group <https://github.com/ansible/community/wiki/AWS>`_ - ``#ansible-aws``"
msgstr "`Amazon (AWS) Working Group <https://github.com/ansible/community/wiki/AWS>`_ - ``#ansible-aws``"
#: ../../rst/community/communication.rst:61
msgid "`Ansible Lockdown Working Group <https://github.com/ansible/community/wiki/Lockdown>`_ | `gh/ansible/ansible-lockdown <https://github.com/ansible/ansible-lockdown>`_ - ``#ansible-lockdown``- Security playbooks/roles"
msgstr "`Ansible Lockdown Working Group <https://github.com/ansible/community/wiki/Lockdown>`_ | `gh/ansible/ansible-lockdown <https://github.com/ansible/ansible-lockdown>`_ - ``#ansible-lockdown``- セキュリティー Playbook およびロール"
#: ../../rst/community/communication.rst:62
msgid "`AWX Working Group <https://github.com/ansible/awx>`_ - ``#ansible-awx`` - Upstream for Ansible Tower"
msgstr "`AWX Working Group <https://github.com/ansible/awx>`_ - ``#ansible-awx`` - Ansible Tower のアップストリーム"
#: ../../rst/community/communication.rst:63
msgid "`Azure Working Group <https://github.com/ansible/community/wiki/Azure>`_ - ``#ansible-azure``"
msgstr "`Azure Working Group <https://github.com/ansible/community/wiki/Azure>`_ - ``#ansible-azure``"
#: ../../rst/community/communication.rst:64
msgid "`Community Working Group <https://github.com/ansible/community/wiki/Community>`_ - ``#ansible-community`` - Including Meetups"
msgstr "`Community Working Group <https://github.com/ansible/community/wiki/Community>`_ - ``#ansible-community`` - Meetup を含みます。"
#: ../../rst/community/communication.rst:65
msgid "`Container Working Group <https://github.com/ansible/community/wiki/Container>`_ - ``#ansible-container``"
msgstr "`Container Working Group <https://github.com/ansible/community/wiki/Container>`_ - ``#ansible-container``"
#: ../../rst/community/communication.rst:66
msgid "`Contributor Experience Working Group <https://github.com/ansible/community/wiki/Contributor-Experience>`_ - ``#ansible-community``"
msgstr "`Contributor Experience Working Group <https://github.com/ansible/community/wiki/Contributor-Experience>`_ - ``#ansible-community``"
#: ../../rst/community/communication.rst:67
msgid "`Docker Working Group <https://github.com/ansible/community/wiki/Docker>`_ - ``#ansible-devel``"
msgstr "`Docker Working Group <https://github.com/ansible/community/wiki/Docker>`_ - ``#ansible-devel``"
#: ../../rst/community/communication.rst:68
msgid "`Documentation Working Group <https://github.com/ansible/community/wiki/Docs>`_- ``#ansible-docs``"
msgstr "`Documentation Working Group <https://github.com/ansible/community/wiki/Docs>`_- ``#ansible-docs``"
#: ../../rst/community/communication.rst:69
msgid "`Galaxy Working Group <https://github.com/ansible/community/wiki/Galaxy>`_ - ``#ansible-galaxy``"
msgstr "`Galaxy Working Group <https://github.com/ansible/community/wiki/Galaxy>`_ - ``#ansible-galaxy``"
#: ../../rst/community/communication.rst:70
msgid "`JBoss Working Group <https://github.com/ansible/community/wiki/JBoss>`_ - ``#ansible-jboss``"
msgstr "`JBoss Working Group <https://github.com/ansible/community/wiki/JBoss>`_ - ``#ansible-jboss``"
#: ../../rst/community/communication.rst:71
msgid "`Kubernetes Working Group <https://github.com/ansible/community/wiki/Kubernetes>`_ - ``#ansible-kubernetes``"
msgstr "`Kubernetes Working Group <https://github.com/ansible/community/wiki/Kubernetes>`_ - ``#ansible-kubernetes``"
#: ../../rst/community/communication.rst:72
msgid "`Lightbulb Training <https://github.com/ansible/lightbulb>`_ - ``#ansible-lightbulb`` - Ansible training"
msgstr "`Lightbulb Training <https://github.com/ansible/lightbulb>`_ - ``#ansible-lightbulb`` - Ansible トレーニング"
#: ../../rst/community/communication.rst:73
msgid "`Linode Working Group <https://github.com/ansible/community/wiki/Linode>`_ - ``#ansible-linode``"
msgstr "`Linode Working Group <https://github.com/ansible/community/wiki/Linode>`_ - ``#ansible-linode``"
#: ../../rst/community/communication.rst:74
msgid "`Molecule Working Group <https://github.com/ansible/community/wiki/Molecule>`_ | `molecule.io <https://molecule.readthedocs.io>`_ - ``#ansible-molecule`` - testing platform for Ansible playbooks and roles"
msgstr "`Molecule Working Group <https://github.com/ansible/community/wiki/Molecule>`_ | `molecule.io <https://molecule.readthedocs.io>`_ - ``#ansible-molecule`` - Ansible Playbook およびロール用テストプラットフォーム"
#: ../../rst/community/communication.rst:75
msgid "`Network Working Group <https://github.com/ansible/community/wiki/Network>`_ - ``#ansible-network``"
msgstr "`Network Working Group <https://github.com/ansible/community/wiki/Network>`_ - ``#ansible-network``"
#: ../../rst/community/communication.rst:76
msgid "`Remote Management Working Group <https://github.com/ansible/community/issues/409>`_ - ``#ansible-devel``"
msgstr "`Remote Management Working Group <https://github.com/ansible/community/issues/409>`_ - ``#ansible-devel``"
#: ../../rst/community/communication.rst:77
msgid "`Testing Working Group <https://github.com/ansible/community/wiki/Testing>`_ - ``#ansible-devel``"
msgstr "`Testing Working Group <https://github.com/ansible/community/wiki/Testing>`_ - ``#ansible-devel``"
#: ../../rst/community/communication.rst:78
msgid "`VMware Working Group <https://github.com/ansible/community/wiki/VMware>`_ - ``#ansible-vmware``"
msgstr "`VMware Working Group <https://github.com/ansible/community/wiki/VMware>`_ - ``#ansible-vmware``"
#: ../../rst/community/communication.rst:79
msgid "`Windows Working Group <https://github.com/ansible/community/wiki/Windows>`_ - ``#ansible-windows``"
msgstr "`Windows Working Group <https://github.com/ansible/community/wiki/Windows>`_ - ``#ansible-windows``"
msgid "The Ansible community holds regular IRC meetings on various topics, and anyone who is interested is invited to participate. For more information about Ansible meetings, consult the `meeting schedule and agenda page <https://github.com/ansible/community/blob/main/meetings/README.md>`_."
msgid "Red Hat Ansible `Tower <https://www.ansible.com/products/tower>`_ is a UI, Server, and REST endpoint for Ansible. The Red Hat Ansible Automation subscription contains support for Ansible, Ansible Tower, Ansible Automation for Networking, and more."
msgstr "Red Hat Ansible `Tower <https://www.ansible.com/products/tower>`_ は、Ansible の UI、サーバー、および REST エンドポイントです。Red Hat Ansible Automation サブスクリプションには、Ansible、Ansible Tower、Ansible Automation for Networking などのサポートが含まれます。"
#: ../../rst/community/communication.rst:103
msgid "If you have a question about Ansible Tower, visit `Red Hat support <https://access.redhat.com/products/ansible-tower-red-hat/>`_ rather than using the IRC channel or the general project mailing list."
msgstr "Ansible Tower に関するご質問は、IRC チャンネルまたは一般的なプロジェクトメーリングリストではなく、`Red Hat サポート <https://access.redhat.com/products/ansible-tower-red-hat/>`_ にお問い合わせください。"
#: ../../rst/community/communication.rst:106
msgid "The Bullhorn"
msgstr "The Bullhorn"
#: ../../rst/community/communication.rst:108
msgid "**The Bullhorn** is our newsletter for the Ansible developer community. If you have any questions or content you would like to share, please reach out to us at the-bullhorn@redhat.com, or directly `contribute/suggest content <https://github.com/ansible/community/issues/546>`_ for upcoming issues."
msgid "The Ansible team welcomes community contributions to the collections maintained by Red Hat Ansible Engineering. This section describes how you can open issues and create PRs with the required testing before your PR can be merged."
msgstr "Ansible チームは、Red Hat Ansible Engineering が管理するコレクションへのコミュニティーの貢献を歓迎します。このセクションでは、PR をマージする前に、問題を作成し、必要なテストで PR を作成する方法を説明します。"
msgid "**Ansible-maintained collection** - Click the link to the collection on Galaxy, then click the ``repo`` button in Galaxy to find the GitHub repository for this collection."
msgid "**Related community collection** - Collection that holds community-created content (modules, roles, and so on) that may also be of interest to a user of the Ansible-maintained collection. You can, for example, add new modules to the community collection as a technical preview before the content is moved to the Ansible-maintained collection."
msgid "**Sponsor** - Working group that manages the collections. You can join the meetings to discuss important proposed changes and enhancements to the collections."
msgid "**Developer details** - Describes whether the Ansible-maintained collection accepts direct community issues and PRs for existing collection content, as well as more specific developer guidelines based on the collection type."
msgid "\\* A ✓ under **Open to PRs** means the collection welcomes GitHub issues and PRs for any changes to existing collection content (plugins, roles, and so on)."
msgid "\\*\\* Integration tests are required and unit tests are welcomed but not required for the AWS collections. An exception to this is made in cases where integration tests are logistically not feasible due to external requirements. An example of this is AWS Direct Connect, as this service can not be functionally tested without the establishment of network peering connections. Unit tests are therefore required for modules that interact with AWS Direct Connect. Exceptions to ``amazon.aws`` must be approved by Red Hat, and exceptions to ``community.aws`` must be approved by the AWS community."
msgstr "\\*\\* 統合テストは必須であり、単体テストは歓迎されますが、AWS コレクションには必須ではありません。これに対する例外は、外部要件により統合テストが永続的に実行できない場合に生じます。この例として、AWS Direct Connect があります。これは、ネットワークピアリング接続を確立しないと、このサービスを機能的にテストできないためです。したがって、AWS Direct Connect と相互作用するモジュールには単体テストが必要です。``amazon.aws`` への例外は Red Hat によって承認され、``community.aws`` への例外は AWS コミュニティーによって承認される必要があります。"
msgid "\\*\\*\\* ``ansible.netcommon`` contains all foundational components for enabling many network and security :ref:`platform <platform_options>` collections. It contains all connection and filter plugins required, and installs as a dependency when you install the platform collection."
msgid "\\*\\*\\*\\* Unit tests for Windows PowerShell modules are an exception to testing, but unit tests are valid and required for the remainder of the collection, including Ansible-side plugins."
msgstr "\\*\\*\\*\\* Windows PowerShell モジュールの単体テストは、テストの例外ですが、単体テストは、Ansible 側のプラグインを含め、コレクションの残りの部分に有効かつ必要になります。"
msgid "We welcome contributions to Ansible-maintained collections. Because these collections are part of a downstream supported Red Hat product, the criteria for contribution, testing, and release may be higher than other community collections. The related community collections (such as ``community.general`` and ``community.network``) have less-stringent requirements and are a great place for new functionality that may become part of the Ansible-maintained collection in a future release."
msgstr "Ansible で管理されているコレクションへの貢献を歓迎します。これらのコレクションは、ダウンストリームでサポートされている Red Hat 製品の一部であるため、貢献、テスト、およびリリースの基準は、他のコミュニティーコレクションよりも高い場合があります。関連するコミュニティーコレクション (``community.general`` および ``community.network`` など) の要件はそれほど厳しくなく、将来のリリースで Ansible が管理するコレクションの一部になる可能性がある新しい機能に最適な場所です。"
msgid "The following scenarios use the ``arista.eos`` to help explain when to contribute to the Ansible-maintained collection, and when to propose your change or idea to the related community collection:"
msgid "You want to fix a problem in the ``arista.eos`` Ansible-maintained collection. Create the PR directly in the `arista.eos collection GitHub repository <https://github.com/ansible-collections/arista.eos>`_. Apply all the :ref:`merge requirements <ansible_collection_merge_requirements>`."
msgid "Most new content should go into either a related community collection or your own collection first so that is well established in the community before you can propose adding it to the ``arista`` namespace, where inclusion and maintenance criteria are much higher."
msgid "The PR is in the intended scope of the collection. Communicate with the appropriate Ansible sponsor listed in the :ref:`Ansible-maintained collection table <ansible-collection-table>` for help."
msgid "Passes unit, and integration tests, as listed in the :ref:`Ansible-maintained collection table <ansible-collection-table>` and described in :ref:`testing_resource_modules`."
msgid "By contributing you agree that these contributions are your own (or approved by your employer) and you grant a full, complete, irrevocable copyright license to all users and developers of the project, present and future, pursuant to the license of the project."
msgstr "By contributing you agree that these contributions are your own (or approved by your employer) and you grant a full, complete, irrevocable copyright license to all users and developers of the project, present and future, pursuant to the license of the project."
#: ../../rst/community/development_process.rst:5
msgid "The Ansible Development Cycle"
msgstr "Ansible 開発ライフサイクル"
#: ../../rst/community/development_process.rst:7
msgid "Ansible developers (including community contributors) add new features, fix bugs, and update code in many different repositories. The `ansible/ansible repository <https://github.com/ansible/ansible>`_ contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-base``. Other repositories contain plugins and modules that enable Ansible to execute specific tasks, like adding a user to a particular database or configuring a particular network device. These repositories contain the source code for collections."
msgid "Development on ``ansible-base`` occurs on two levels. At the macro level, the ``ansible-base`` developers and maintainers plan releases and track progress with roadmaps and projects. At the micro level, each PR has its own lifecycle."
msgid "Development on collections also occurs at the macro and micro levels. Each collection has its own macro development cycle. For more information on the collections development cycle, see :ref:`contributing_maintained_collections`. The micro-level lifecycle of a PR is similar in collections and in ``ansible-base``."
msgid "If you want to follow the conversation about what features will be added to ``ansible-base`` for upcoming releases and what bugs are being fixed, you can watch these resources:"
msgid "If you want to contribute a feature or fix a bug in ``ansible-base`` or in a collection, you must open a **pull request** (\"PR\" for short). GitHub provides a great overview of `how the pull request process works <https://help.github.com/articles/about-pull-requests/>`_ in general. The ultimate goal of any pull request is to get merged and become part of a collection or ``ansible-base``. Here's an overview of the PR lifecycle:"
msgid "Developers, maintainers, community review the PR"
msgstr "開発者、メンテナー、コミュニティーがプル要求をレビューします。"
#: ../../rst/community/development_process.rst:43
msgid "Contributor addresses any feedback from reviewers"
msgstr "貢献者が、レビューアーからのフィードバックに対処します。"
#: ../../rst/community/development_process.rst:44
msgid "Developers, maintainers, community re-review"
msgstr "開発者、メンテナー、コミュニティーが再度レビューします。"
#: ../../rst/community/development_process.rst:45
msgid "PR merged or closed"
msgstr "プル要求をマージまたは終了します。"
#: ../../rst/community/development_process.rst:48
msgid "Automated PR review: ansibullbot"
msgstr "自動プル要求確認: ansibullbot"
#: ../../rst/community/development_process.rst:50
msgid "Because Ansible receives many pull requests, and because we love automating things, we have automated several steps of the process of reviewing and merging pull requests with a tool called Ansibullbot, or Ansibot for short."
msgid "Ansibullbot runs continuously. You can generally expect to see changes to your issue or pull request within thirty minutes. Ansibullbot examines every open pull request in the repositories, and enforces state roughly according to the following workflow:"
msgid "If a pull request has no workflow labels, it's considered **new**. Files in the pull request are identified, and the maintainers of those files are pinged by the bot, along with instructions on how to review the pull request. (Note: sometimes we strip labels from a pull request to \"reboot\" this process.)"
msgid "If the submitter says ``ready_for_review``, the pull request is put back into **community_review** or **core_review** and the maintainer is notified that the pull request is ready to be reviewed again."
msgid "The submitter is first politely pinged after two weeks, pinged again after two more weeks and labeled **pending action**, and the issue or pull request will be closed two weeks after that."
msgid "The reviewer is first politely pinged after two weeks, pinged again after two more weeks and labeled **pending_action**, and then may be reassigned to ``$team_ansible`` or labeled **core_review**, or often the submitter of the pull request is asked to step up as a maintainer."
msgid "If Shippable tests fail, or if the code is not able to be merged, the pull request is automatically put into **needs_revision** along with a message to the submitter explaining why."
msgid "**backport**: this is applied automatically if the PR is requested against any branch that is not devel. The bot immediately assigns the labels backport and ``core_review``."
msgid "**owner_pr**: largely deprecated. Formerly workflow, now informational. Originally, PRs submitted by the maintainer would automatically go to **shipit** based on this label. If the submitter is also a maintainer, we notify the other maintainers and still require one of the maintainers (including the submitter) to give a **shipit**."
msgid "**pending_action**: applied by the bot to PRs that are not moving. Reviewed every couple of weeks by the community team, who tries to figure out the appropriate action (closure, asking for new maintainers, and so on)."
msgid "**Note:** `new_plugin` kicks off a completely separate process, and frankly it doesn't work very well at present. We're working our best to improve this process."
msgid "After Ansibot reviews the PR and applies labels, the PR is ready for human review. The most likely reviewers for any PR are the maintainers for the module that PR modifies."
msgid "Each module has at least one assigned :ref:`maintainer <maintainers>`, listed in the `BOTMETA.yml <https://github.com/ansible/ansible/blob/devel/.github/BOTMETA.yml>`_ file."
msgid "The maintainer's job is to review PRs that affect that module and decide whether they should be merged (``shipit``) or revised (``needs_revision``). We'd like to have at least one community maintainer for every module. If a module has no community maintainers assigned, the maintainer is listed as ``$team_ansible``."
msgid "Once a human applies the ``shipit`` label, the :ref:`committers <community_committer_guidelines>` decide whether the PR is ready to be merged. Not every PR that gets the ``shipit`` label is actually ready to be merged, but the better our reviewers are, and the better our guidelines are, the more likely it will be that a PR that reaches **shipit** will be mergeable."
msgid "Changelogs help users and developers keep up with changes to Ansible. Ansible builds a changelog for each release from fragments. You **must** add a changelog fragment to any PR that changes functionality or fixes a bug in ansible-base. You do not have to add a changelog fragment for PRs that add new modules and plugins, because our tooling does that for you automatically."
msgid "We build short summary changelogs for minor releases as well as for major releases. If you backport a bugfix, include a changelog fragment with the backport PR."
msgid "A basic changelog fragment is a ``.yaml`` file placed in the ``changelogs/fragments/`` directory. Each file contains a yaml dict with keys like ``bugfixes`` or ``major_changes`` followed by a list of changelog entries of bugfixes or features. Each changelog entry is rst embedded inside of the yaml file which means that certain constructs would need to be escaped so they can be interpreted by rst and not by yaml (or escaped for both yaml and rst if you prefer). Each PR **must** use a new fragment file rather than adding to an existing one, so we can trace the change back to the PR that introduced it."
msgid "To create a changelog entry, create a new file with a unique name in the ``changelogs/fragments/`` directory of the corresponding repository. The file name should include the PR number and a description of the change. It must end with the file extension ``.yaml``. For example: ``40696-user-backup-shadow-file.yaml``"
msgid "A single changelog fragment may contain multiple sections but most will only contain one section. The toplevel keys (bugfixes, major_changes, and so on) are defined in the `config file <https://github.com/ansible/ansible/blob/devel/changelogs/config.yaml>`_ for our `release note tool <https://github.com/ansible-community/antsibull-changelog/blob/main/docs/changelogs.rst>`_. Here are the valid sections and a description of each:"
msgid "Changes that break existing playbooks or roles. This includes any change to existing behavior that forces users to update tasks. Displayed in both the changelogs and the :ref:`Porting Guides <porting_guides>`."
msgid "Major changes to Ansible itself. Generally does not include module or plugin changes. Displayed in both the changelogs and the :ref:`Porting Guides <porting_guides>`."
msgid "Minor changes to Ansible, modules, or plugins. This includes new features, new parameters added to modules, or behavior changes to existing parameters."
msgid "Features that have been deprecated and are scheduled for removal in a future release. Displayed in both the changelogs and the :ref:`Porting Guides <porting_guides>`."
msgid "Each changelog entry must contain a link to its issue between parentheses at the end. If there is no corresponding issue, the entry must contain a link to the PR itself."
msgid "Most changelog entries will be ``bugfixes`` or ``minor_changes``. When writing a changelog entry that pertains to a particular module, start the entry with ``- [module name] -`` and the following sentence with a lowercase letter."
msgid "You can find more example changelog fragments in the `changelog directory <https://github.com/ansible/ansible/tree/stable-2.10/changelogs/fragments>`_ for the 2.10 release."
msgid "All ``ansible-base`` PRs must be merged to the ``devel`` branch first. After a pull request has been accepted and merged to the ``devel`` branch, the following instructions will help you create a pull request to backport the change to a previous stable branch."
msgid "``https://github.com/ansible/ansible.git`` is configured as a ``git remote`` named ``upstream``. If you do not use a ``git remote`` named ``upstream``, adjust the instructions accordingly."
msgid "``https://github.com/<yourgithubaccount>/ansible.git`` is configured as a ``git remote`` named ``origin``. If you do not use a ``git remote`` named ``origin``, adjust the instructions accordingly."
msgid "The Release Manager will decide whether to merge the backport PR before the next minor release. There isn't any need to follow up. Just ensure that the automated tests (CI) are green."
msgid "The choice to use ``backport/2.10/[PR_NUMBER_FROM_DEVEL]`` as the name for the feature branch is somewhat arbitrary, but conveys meaning about the purpose of that branch. It is not required to use this format, but it can be helpful, especially when making multiple backport PRs for multiple stable branches."
msgid "If you prefer, you can use CPython's cherry-picker tool (``pip install --user 'cherry-picker >= 1.3.2'``) to backport commits from devel to stable branches in Ansible. Take a look at the `cherry-picker documentation <https://pypi.org/p/cherry-picker#cherry-picking>`_ for details on installing, configuring, and using it."
msgid "Improving the documentation is an easy way to make your first contribution to the Ansible project. You do not have to be a programmer, since most of our documentation is written in YAML (module documentation) or `reStructuredText <https://docutils.sourceforge.io/rst.html>`_ (rST). Some collection-level documentation is written in a subset of `Markdown <https://github.com/ansible/ansible/issues/68119#issuecomment-596723053>`_. If you are using Ansible, you already use YAML in your playbooks. rST and Markdown are mostly just text. You do not even need git experience, if you use the ``Edit on GitHub`` option."
msgid "If you find a typo, a broken example, a missing topic, or any other error or omission on this documentation website, let us know. Here are some ways to support Ansible documentation:"
msgstr "このドキュメントの Web サイトで、タ誤字や不備のある例、欠落しているトピック、またはその他のエラーや省略を見つけたらご連絡ください。Ansible ドキュメントをサポートする方法は次のとおりです。"
msgid "For typos and other quick fixes, you can edit most of the documentation right from the site. Look at the top right corner of this page. That ``Edit on GitHub`` link is available on all the guide pages in the documentation. If you have a GitHub account, you can submit a quick and easy pull request this way."
msgstr "入力ミスやその他の簡単な修正は、サイトから直接ドキュメントを編集できます。このページの右上を見てください。``Edit on GitHub`` リンクは、ドキュメント内のすべてのページで利用できます。GitHub アカウントがある場合は、この方法で迅速かつ簡単なプル要求を送信できます。"
msgid "The source files for individual collection plugins exist in their respective repositories. Follow the link to the collection on Galaxy to find where the repository is located and any guidelines on how to contribute to that collection."
msgid "Enter a commit message in the first rectangle under the heading ``Propose file change`` at the bottom of the GitHub page. The more specific, the better. For example, \"fixes typo in my_module description\". You can put more detail in the second rectangle if you like. Leave the ``+label: docsite_pr`` there."
msgid "Submit the suggested change by clicking on the green \"Propose file change\" button. GitHub will handle branching and committing for you, and open a page with the heading \"Comparing Changes\"."
msgid "Fill out the PR template, including as much detail as appropriate for your change. You can change the title of your PR if you like (by default it's the same as your commit message). In the ``Issue Type`` section, delete all lines except the ``Docs Pull Request`` line."
msgid "You can also contribute by reviewing open documentation `issues <https://github.com/ansible/ansible/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Adocs>`_ and `PRs <https://github.com/ansible/ansible/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+label%3Adocs>`_. To add a helpful review, please:"
msgid "If the problem you have noticed is too complex to fix with the ``Edit on GitHub`` option, and no open issue or PR already documents the problem, please open an issue and/or a PR on the correct underlying repo - ``ansible/ansible`` for most pages that are not plugin or module documentation. If the documentation page has no ``Edit on GitHub`` option, check if the page is for a module within a collection. If so, follow the link to the collection on Galaxy and select the ``repo`` button in the upper right corner to find the source repository for that collection and module. The Collection README file should contain information on how to contribute to that collection, or report issues."
msgstr "気づいた問題が複雑すぎて ``Edit on GitHub`` オプションでは修正できず、その問題が報告されていなかったり、プル要求が作成されていない場合は、正しい基盤のリポジトリーで問題またはプル要求を作成してください (プラグインやモジュールのドキュメント以外のほとんどのページについては、``ansible/ansible`` で問題またはプル要求を作成してください)。ドキュメントページに ``Edit on GitHub`` オプションがない場合は、そのページがコレクション内のモジュール用であるかどうかを確認します。その場合は、Galaxy のコレクションへのリンクに従い、右上隅の ``repo`` ボタンを選択して、そのコレクションとモジュールのソースリポジトリーを見つけてください。コレクション README ファイルには、そのコレクションへの貢献方法、または問題を報告する方法に関する情報が含まれているはずです。"
msgid "a detailed description of the problem (even for a PR - it's hard to evaluate a suggested change unless we know what problem it's meant to solve)"
msgid "If you make multiple changes to the documentation on ``ansible/ansible``, or add more than a line to it, before you open a pull request, please:"
msgid "The following sections apply to documentation sourced from the ``ansible/ansible`` repo and does not apply to documentation from an individual collection. See the collection README file for details on how to contribute to that collection."
msgid "After checking out ``ansible/ansible``, make sure the ``docs/docsite/rst`` directory has strict enough permissions. It should only be writable by the owner's account. If your default ``umask`` is not 022, you can use ``chmod go-w docs/docsite/rst`` to set the permissions correctly in your new branch. Optionally, you can set your ``umask`` to 022 to make all newly created files on your system (including those created by ``git clone``) have the correct permissions."
msgid "Building the documentation is the best way to check for errors and review your changes. Once `rstcheck` runs with no errors, navigate to ``ansible/docs/docsite`` and then build the page(s) you want to review."
msgid "This process compiles all the links but provides minimal log output. If you're writing a new page or want more detailed log output, refer to the instructions on :ref:`build_with_sphinx-build`"
msgid "``make htmlsingle`` adds ``rst/`` to the beginning of the path you provide in ``rst=``, so you can't type the filename with autocomplete. Here are the error messages you will see if you get this wrong:"
msgid "If you run ``make htmlsingle`` from the ``docs/docsite/`` directory with the full path to your rST document: ``sphinx-build: error: cannot find files ['rst/rst/community/documentation_contributions.rst']``."
msgid "Advanced users can build one or more rST files with the sphinx utility directly. ``sphinx-build`` returns misleading ``undefined label`` warnings if you only build a single page, because it does not create internal links. However, ``sphinx-build`` returns more extensive syntax feedback, including warnings about indentation errors and ``x-string without end-string`` warnings. This can be useful, especially if you're creating a new page from scratch. To build a page or pages with ``sphinx-build``:"
msgid "When you submit a documentation pull request, automated tests are run. Those same tests can be run locally. To do so, navigate to the repository's top directory and run:"
msgid "Unfortunately, leftover rST-files from previous document-generating can occasionally confuse these tests. It is therefore safest to run them on a clean copy of the repository, which is the purpose of ``make clean``. If you type these three lines one at a time and manually check the success of each, you do not need the ``&&``."
msgid "The Documentation Working Group (DaWGs) meets weekly on Tuesdays on the #ansible-docs channel on freenode IRC. For more information, including links to our agenda and a calendar invite, please visit the `working group page in the community repo <https://github.com/ansible/community/wiki/Docs>`_."
msgid ":ref:`More about documenting modules <module_documenting>`"
msgstr ":ref:`More about documenting modules <module_documenting>`"
#: ../../rst/community/github_admins.rst:5
msgid "GitHub Admins"
msgstr "GitHub 管理者"
#: ../../rst/community/github_admins.rst:9
msgid "GitHub Admins have more permissions on GitHub than normal contributors or even committers. There are a few responsibilities that come with that increased power."
msgid "The Ansible Team will periodically review who is actively contributing to Ansible to grant or revoke contributors' ability to commit on their own. GitHub Admins are the people who have the power to actually manage the GitHub permissions."
msgid "When we make releases we make people go through a :ref:`release_managers` to push commits to that branch. The GitHub admins are responsible for setting the branch so only the Release Manager can commit to the branch when the release process reaches that stage and later opening the branch once the release has been made. The Release manager will let the GitHub Admin know when this needs to be done."
msgid "The `GitHub Admin Process Docs <https://docs.google.com/document/d/1gWPtxNX4J39uIzwqQWLIsTZ1dY_AwEZzAd9bJ4XtZso/edit#heading=h.2wezayw9xsqz>`_ for instructions on how to change branch permissions."
msgstr "ブランチパーミッションを変更する方法は、「`GitHub Admin Process Docs <https://docs.google.com/document/d/1gWPtxNX4J39uIzwqQWLIsTZ1dY_AwEZzAd9bJ4XtZso/edit#heading=h.2wezayw9xsqz>`_」を参照してください。"
#: ../../rst/community/how_can_I_help.rst:5
msgid "How can I help?"
msgstr "貢献方法"
#: ../../rst/community/how_can_I_help.rst:10
msgid "Thanks for being interested in helping the Ansible project!"
msgid "Study some of the `many excellent books <https://www.amazon.com/s/ref=nb_sb_ss_c_2_7?url=search-alias%3Dstripbooks&field-keywords=ansible&sprefix=ansible%2Caps%2C260>`_ about Ansible"
msgid "Review, fix, and maintain the documentation"
msgstr "ドキュメントの確認、修正、および維持"
#: ../../rst/community/how_can_I_help.rst:37
msgid "Typos are everywhere, even in the Ansible documentation. We work hard to keep the documentation up-to-date, but you may also find outdated examples. We offer easy ways to :ref:`report and/or fix documentation errors <community_documentation_contributions>`."
msgid "There are Ansible meetups `all over the world <https://www.meetup.com/topics/ansible/>`_. Join your local meetup. Attend regularly. Ask good questions. Volunteer to give a presentation about how you use Ansible."
msgid "All software has bugs, and Ansible is no exception. When you find a bug, you can help tremendously by :ref:`telling us about it <reporting_bugs_and_features>`."
msgid "If the bug you found already exists in an issue, you can help by verifying the behavior of the reported bug with a comment in that issue, or by reporting any additional information."
msgid "As you become more familiar with how Ansible works, you may be able to fix issues or develop new features yourself. If you think you have a fix for a bug in Ansible, or if you have a new feature that you would like to share with millions of Ansible users, read all about the :ref:`Ansible development process <community_development_process>` and and :ref:`how to contribute to collections <contributing_maintained_collections>` to learn how to get your code accepted into Ansible."
msgid "Another good way to help is to review pull requests that other Ansible users have submitted. The Ansible community keeps a full list of `open pull requests by file <https://ansible.sivel.net/pr/byfile.html>`_, so if a particular module or plugin interests you, you can easily keep track of all the relevant new pull requests and provide testing or feedback."
msgid "Once you have learned about the development process and have contributed code to a collection, we encourage you to become a maintainer of that collection. There are hundreds of modules in dozens of Ansible collections, and the vast majority of them are written and maintained entirely by members of the Ansible community."
msgid "To learn more about the responsibilities of being an Ansible module maintainer, please read our :ref:`collection maintainer guidelines <maintainers>`."
msgid "Working groups are a way for Ansible community members to self-organize around particular topics of interest. We have working groups around various topics. To join or create a working group, please read the :ref:`Ansible Working Groups<working_group_list>`."
msgid "We are working on a standardized `Ansible workshop <https://ansible.github.io/workshops/>`_ that can provide a good hands-on introduction to Ansible usage and concepts."
msgid "If you like Ansible and just want to spread the good word, feel free to share on your social media platform of choice, and let us know by using ``@ansible`` or ``#ansible``. We'll be looking for you."
msgid "Guidelines for specific types of contributors"
msgstr "貢献者向け各ガイドライン"
#: ../../rst/community/index.rst:5
msgid "Ansible Community Guide"
msgstr "Ansible コミュニティーガイド"
#: ../../rst/community/index.rst:9
msgid "**Making Open Source More Inclusive**"
msgstr "**多様性を受け入れるオープンソースの強化**"
#: ../../rst/community/index.rst:11
msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message <https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language>`_."
msgid "The purpose of this guide is to teach you everything you need to know about being a contributing member of the Ansible community. All types of contributions are welcome and necessary to Ansible's continued success."
msgid "This page outlines the most common situations and questions that bring readers to this section. If you prefer a :ref:`traditional table of contents <community_toc>`, you can find one at the bottom of the page."
msgid "I have a specific Ansible interest or expertise (for example, VMware, Linode, and so on). How do I get involved in a :ref:`working group <working_group_list>`?"
msgid "I want to make my first code changes to a collection or to ``ansible-base``. How do I :ref:`set up my Python development environment <environment_setup>`?"
msgid "I would like to get more efficient as a developer. How can I find :ref:`editors, linters, and other tools <other_tools_and_programs>` that will support my Ansible development efforts?"
msgid "I want to learn more about Ansible roadmaps, releases, and projects. How do I find information on :ref:`the development cycle <community_development_process>`?"
msgid "I am using an older version of Ansible and want a bug fixed in my version that has already been fixed on the ``devel`` branch. How do I :ref:`backport a bugfix PR <backport_process>`?"
msgid "Thank you for being a community collection maintainer. This guide offers an overview of your responsibilities as a maintainer along with resources for additional information. The Ansible community hopes that you will find that maintaining a collection is as rewarding for you as having the collection content is for the wider community."
msgid "When you contribute a module to a collection included in the ``ansible`` package, you become a maintainer for that module once it has been merged. Maintainership empowers you with the authority to accept, reject, or request revisions to pull requests on your module -- but as they say, \"with great power comes great responsibility.\""
msgid "Maintainers of Ansible collections are expected to provide feedback, responses, or actions on pull requests or issues to the collection(s) they maintain in a reasonably timely manner. You can also update the contributor guidelines for that collection, in collaboration with the Ansible community team and the other maintainers of that collection."
msgid "Please see :ref:`communication` for ways to contact the broader Ansible community. For maintainers, following the `ansible-devel <https://groups.google.com/forum/#!forum/ansible-devel>`_ mailing list is a great way to participate in conversations about coding, get assistance when you need it, and influence the overall direction, quality, and goals of Ansible and the collections. If you are not on this relatively low-volume list, please join us here: https://groups.google.com/forum/#!forum/ansible-devel"
msgid "Each collection community can set its own rules and workflow for managing pull requests, bug reports, documentation issues, and feature requests, as well as adding and replacing maintainers."
msgid "An open-source, free GUI text editor created and maintained by GitHub. You can keep track of git project changes, commit from the GUI, and see what branch you are on. You can customize the themes for different colors and install syntax highlighting packages for different languages. You can install Atom on Linux, macOS and Windows. Useful Atom plugins include:"
msgstr "GitHub で作成および保守されるオープンソースの無料 GUI テキストエディター。git プロジェクトの変更を追跡したり、GUI からコミットしたり、自分がどのブランチにいるかを確認できます。テーマをカスタマイズして色を変えたり、言語ごとに構文強調表示パッケージをインストールしたりできます。Atom は、Linux、macOS、および Windows にインストールできます。便利な Atom プラグインには以下が含まれます。"
msgid "A full IDE (integrated development environment) for Python software development. It ships with everything you need to write python scripts and complete software, including support for YAML syntax highlighting. It's a little overkill for writing roles/playbooks, but it can be a very useful tool if you write modules and submit code for Ansible. Can be used to debug the Ansible engine."
msgstr "Python ソフトウェア開発向けの完全な IDE (統合開発環境)。これには、YAML 構文強調表示のサポートを含む、Python スクリプトを記述するのに必要なすべてのものと完全なソフトウェアが同梱されています。ロール/Playbook の作成には少し時間がかかりますが、モジュールを作成し、Ansible 用のコードを送信する場合は、非常に便利なツールになります。Ansible エンジンのデバッグに使用できます。"
msgid "A closed-source, subscription GUI text editor. You can customize the GUI with themes and install packages for language highlighting and other refinements. You can install Sublime on Linux, macOS and Windows. Useful Sublime plugins include:"
msgid "`SideBarEnhancements <https://packagecontrol.io/packages/SideBarEnhancements>`_ - provides enhancements to the operations on Sidebar of Files and Folders."
msgid "`YAML Support by Red Hat <https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml>`_ - provides YAML support through yaml-language-server with built-in Kubernetes and Kedge syntax support."
msgstr "`YAML Support by Red Hat <https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml>`_ - Kubernetes と Kedge の構文サポートを組み込んだ yaml-language-server を通じて YAML サポートを提供します。"
msgid "`Visual Studio Code extension for Ansible <https://marketplace.visualstudio.com/items?itemName=vscoss.vscode-ansible>`_ - provides autocompletion, syntax highlighting."
msgstr "`Visual Studio Code extension for Ansible <https://marketplace.visualstudio.com/items?itemName=vscoss.vscode-ansible>`_ - オートコンプリート、構文強調表示を提供します。"
msgid "`Ansible vim <https://github.com/pearofducks/ansible-vim>`_ - vim syntax plugin for Ansible 2.x, it supports YAML playbooks, Jinja2 templates, and Ansible's hosts files."
msgstr "`Ansible vim <https://github.com/pearofducks/ansible-vim>`_ - Ansible 2.x の vim 構文プラグイン。YAML Playbook、Jinja2 テンプレート、および Ansible ホストファイルをサポートします。"
msgid "An open-source Community edition and closed-source Enterprise edition, integrated development environments based on IntelliJ's framework including IDEA, AppCode, CLion, GoLand, PhpStorm, PyCharm and others. Useful JetBrains platform plugins include:"
msgid "`Ansible <https://plugins.jetbrains.com/plugin/14893-ansible>`_ - general Ansible plugin provides auto-completion, role name suggestion and other handy features for working with playbooks and roles."
msgid "`PR by File <https://ansible.sivel.net/pr/byfile.html>`_ - shows a current list of all open pull requests by individual file. An essential tool for Ansible module maintainers."
msgid "`yamllint <https://yamllint.readthedocs.io/en/stable/>`__ - a command-line utility to check syntax validity including key repetition and indentation issues."
msgid "`Ansible cmdb <https://github.com/fboender/ansible-cmdb>`_ - takes the output of Ansible's fact gathering and converts it into a static HTML overview page containing system configuration information."
msgstr "`Ansible cmdb <https://github.com/fboender/ansible-cmdb>`_ - Ansible のファクト収集の出力を受け取り、システム設定情報が含まれる静的 HTML 概要ページに変換します。"
msgid "`Ansible Inventory Grapher <https://github.com/willthames/ansible-inventory-grapher>`_ - visually displays inventory inheritance hierarchies and at what level a variable is defined in inventory."
msgid "`Ansible Playbook Grapher <https://github.com/haidaraM/ansible-playbook-grapher>`_ - a command line tool to create a graph representing your Ansible playbook tasks and roles."
msgid "`Ansible Shell <https://github.com/dominis/ansible-shell>`_ - an interactive shell for Ansible with built-in tab completion for all the modules."
msgid "`ARA <https://github.com/openstack/ara>`_ - records Ansible playbook runs and makes the recorded data available and intuitive for users and systems by integrating with Ansible as a callback plugin."
msgid "`AWX <https://github.com/ansible/awx>`_ - provides a web-based user interface, REST API, and task engine built on top of Ansible. AWX is the upstream project for Red Hat Ansible Tower, part of the Red Hat Ansible Automation subscription."
msgstr "`AWX <https://github.com/ansible/awx>`_ - Ansible 上に構築された Web ベースのユーザーインターフェース、REST API、およびタスクエンジンを提供します。AWX は、Red Hat Ansible Automation サブスクリプションに含まれる Red Hat Ansible Tower のアップストリームプロジェクトです。"
msgid "`Mitogen for Ansible <https://mitogen.networkgenomics.com/ansible_detailed.html>`_ - uses the `Mitogen <https://github.com/dw/mitogen/>`_ library to execute Ansible playbooks in a more efficient way (decreases the execution time)."
msgid "`nanvault <https://github.com/marcobellaccini/nanvault>`_ - a standalone tool to encrypt and decrypt files in the Ansible Vault format, featuring UNIX-style composability."
msgid "`OpsTools-ansible <https://github.com/centos-opstools/opstools-ansible>`_ - uses Ansible to configure an environment that provides the support of `OpsTools <https://wiki.centos.org/SpecialInterestGroup/OpsTools>`_, namely centralized logging and analysis, availability monitoring, and performance monitoring."
msgid "`TD4A <https://github.com/cidrblock/td4a>`_ - a template designer for automation. TD4A is a visual design aid for building and testing jinja2 templates. It will combine data in yaml format with a jinja2 template and render the output."
msgid "Pre-releases exist to draw testers. They give people who don't feel comfortable running from source control a means to get an early version of the code to test and give us feedback. To ensure we get good feedback about a release, we need to make sure all major changes in a release are put into a pre-release. Testers must be given time to test those changes before the final release. Ideally we want there to be sufficient time between pre-releases for people to install and test one version for a span of time. Then they can spend more time using the new code than installing the latest version."
msgid "The right length of time for a tester is probably around two weeks. However, for our three-to-four month development cycle to work, we compress this down to one week; any less runs the risk of people spending more time installing the code instead of running it. However, if there's a time crunch (with a release date that cannot slip), it is better to release with new changes than to hold back those changes to give people time to test between. People cannot test what is not released, so we have to get those tarballs out there even if people feel they have to install more frequently."
msgid "In a beta release, we know there are still bugs. We will continue to accept fixes for these. Although we review these fixes, sometimes they can be invasive or potentially destabilize other areas of the code."
msgid "During the beta, we will no longer accept feature submissions."
msgstr "ベータ版では、機能の提出は受け付けなくなります。"
#: ../../rst/community/release_managers.rst:48
msgid "Release candidates"
msgstr "Release Candidate (リリースの候補)"
#: ../../rst/community/release_managers.rst:50
msgid "In a release candidate, we've fixed all known blockers. Any remaining bugfixes are ones that we are willing to leave out of the release. At this point we need user testing to determine if there are any other blocker bugs lurking."
msgid "Blocker bugs generally are those that cause significant problems for users. Regressions are more likely to be considered blockers because they will break present users' usage of Ansible."
msgid "The Release Manager will cherry-pick fixes for new release blockers. The release manager will also choose whether to accept bugfixes for isolated areas of the code or defer those to the next minor release. By themselves, non-blocker bugs will not trigger a new release; they will only make it into the next major release if blocker bugs require that a new release be made."
msgid "Tests and :file:`docs/docsite/` can differ if really needed as they do not break runtime. However, the release manager may still reject them as they have the potential to cause breakage that will be visible during the release process."
msgid "We want to specifically emphasize that code (in :file:`bin/`, :file:`lib/ansible/`, and :file:`setup.py`) must be the same unless there are extraordinary extenuating circumstances. If there are extenuating circumstances, the Release Manager is responsible for notifying groups (like the Tower Team) which would want to test the code."
msgid "The release process is kept in a `separate document <https://docs.google.com/document/d/10EWLkMesi9s_CK_GmbZlE_ZLhuQr6TBrdMLKo5dnMAI/edit#heading=h.ooo3izcel3cz>`_ so that it can be easily updated during a release. If you need access to edit this, please ask one of the current release managers to add you."
msgid "Ansible practices responsible disclosure - if this is a security-related bug, email `security@ansible.com <mailto:security@ansible.com>`_ instead of filing a ticket or posting to any public groups, and you will receive a prompt response."
msgid "If you find a bug that affects multiple plugins, a plugin that remained in the ansible/ansible repo, or the overall functioning of Ansible, report it to `github.com/ansible/ansible/issues <https://github.com/ansible/ansible/issues>`_. You need a free GitHub account. Before reporting a bug, use the bug/issue search to see if the issue has already been reported. If you are not sure if something is a bug yet, you can report the behavior on the :ref:`mailing list or IRC first <communication>`."
msgid "Do not open issues for \"how do I do this\" type questions. These are great topics for IRC or the mailing list, where things are likely to be more of a discussion."
msgstr "「How do I do this (どうすればいいのか)」というタイプの質問で、問題を作成しないでください。このタイプの問題は、物事がより多くの議論になる可能性が高い IRC またはメーリングリストにとって素晴らしいトピックです。"
msgid "If you find a bug, open the issue yourself to ensure we have a record of it. Do not rely on someone else in the community to file the bug report for you. We have created an issue template, which saves time and helps us help everyone with their issues more quickly. Please fill it out as completely and as accurately as possible:"
msgid "Provide steps to reproduce the bug * Use minimal well-reduced and well-commented examples, not your entire production playbook * When sharing YAML in playbooks, preserve the formatting by using `code blocks <https://help.github.com/articles/creating-and-highlighting-code-blocks/>`_."
msgid "Many bugs only affect a single module or plugin. If you find a bug that affects a module or plugin hosted in a collection, file the bug in the repository of the :ref:`collection <collections>`:"
msgid "If you are not sure whether a bug is in ansible-base or in a collection, you can report the behavior on the :ref:`mailing list or IRC first <communication>`."
msgid "The best way to get a feature into Ansible is to :ref:`submit a pull request <community_pull_requests>`, either against ansible-base or against a collection. See also :ref:`ansible_collection_merge_requirements`."
msgid "The issue and PR triage processes are driven by the `Ansibot <https://github.com/ansible/ansibullbot>`_. Whenever an issue or PR is filed, the Ansibot examines the issue to ensure that all relevant data is present, and handles the routing of the issue as it works its way to eventual completion."
msgid "For details on how Ansibot manages the triage process, please consult the `Ansibot Issue Guide <https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md>`_."
