Merge branch 'master' into translation

Author: mlinksva

Gemfile.lock

@@ -28,7 +28,7 @@ GEM
     execjs (2.7.0)
     faraday (1.0.0)
       multipart-post (>= 1.2, < 3)
-    ffi (1.12.1)
+    ffi (1.12.2)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
     github-pages (204)
@@ -83,7 +83,7 @@ GEM
     html-pipeline (2.12.3)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.15.1)
+    html-proofer (3.15.3)
       addressable (~> 2.3)
       mercenary (~> 0.3)
       nokogumbo (~> 2.0)
@@ -212,7 +212,7 @@ GEM
       jekyll-seo-tag (~> 2.1)
     minitest (5.14.0)
     multipart-post (2.1.1)
-    nokogiri (1.10.8)
+    nokogiri (1.10.9)
       mini_portile2 (~> 2.4.0)
     nokogumbo (2.0.2)
       nokogiri (~> 1.8, >= 1.8.4)
@@ -249,7 +249,7 @@ GEM
     tzinfo (1.2.6)
       thread_safe (~> 0.1)
     unicode-display_width (1.6.1)
-    yell (2.2.1)
+    yell (2.2.2)
     zeitwerk (2.2.2)
 
 PLATFORMS

_articles/de/best-practices.md

@@ -113,7 +113,7 @@ Wenn Sie einen Beitrag erhalten, den Sie nicht annehmen möchten, könnte Ihre e
 
 Lassen Sie keinen unerwünschten Beitrag offen, weil Sie sich schuldig fühlen oder nett sein wollen. Im Laufe der Zeit werden unbeantwortete Issues und PRs die Projektarbeit stressiger und einschüchternder machen.
 
-Schließen Sie Beiträge lieber sofort, von denen Sie wissen, dass Sie sie nicht annehmen wollen. Wenn Ihr Projekt bereits unter einem großen Rückstand leidet, hat @steveklabnik Vorschläge für [eine effiziente Behandlung von Issues](http://words.steveklabnik.com/how-to-be-an-open-source-gardener) (Englisch).
+Schließen Sie Beiträge lieber sofort, von denen Sie wissen, dass Sie sie nicht annehmen wollen. Wenn Ihr Projekt bereits unter einem großen Rückstand leidet, hat @steveklabnik Vorschläge für [eine effiziente Behandlung von Issues](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) (Englisch).
 
 Zweitens sendet das Ignorieren von Beiträgen ein negatives Signal an die Gemeinschaft um Ihr Projekt. Einen Projektbeitrag einzureichen, kann einschüchternd sein, besonders für Neulinge. Auch wenn Sie ihren Beitrag nicht annehmen, danken Sie der einreichenden Person für ihr Interesse. Das ist ein großes Kompliment!
 

_articles/de/building-community.md

@@ -63,7 +63,7 @@ Andere zur Mitarbeit zu ermutigen, ist auch eine Investition in sich selbst: Wen
   _Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening._
 
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source"](http://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -287,7 +287,7 @@ Wenn eine Diskussion offensichtlich nirgendwo hinführt, es keine klaren Maßnah
   _Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct._
 
   <p markdown="1" class="pquote-credit">
-— @kfogel, [_Producing OSS_](http://producingoss.com/en/producingoss.html#common-pitfalls)
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
   </p>
 </aside>
 

_articles/de/how-to-contribute.md

@@ -473,7 +473,7 @@ Ein Projekt, das freundlich und einladend ist, signalisiert Offenheit gegenüber
   _Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development._
 
   <p markdown="1" class="pquote-credit">
-— @kfogel, [_Producing OSS_](http://producingoss.com/en/evaluating-oss-projects.html)
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
   </p>
 </aside>
 

_articles/de/starting-a-project.md

@@ -270,7 +270,7 @@ Egal ob offizielle Dokumentation oder informelle E-Mail: Ihr Schreibstil ist ein
   _I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style._
 
   <p markdown="1" class="pquote-credit">
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](http://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 

_articles/es/how-to-contribute.md

@@ -172,7 +172,7 @@ Un proyecto de código abierto tiene los siguientes tipos de personas:
 * **Colaboradores:** Cualquiera que haya contribuido con algo al proyecto.
 * **Miembros de la comunidad:** Las personas que utilizan al proyecto. Pueden tener un rol activo en las conversaciones o expresar su opinión sobre la dirección que toma el proyecto.
 
-Los proyectos más grandes pueden tener también subcomisiones o grupos de trabajo enfocados en tareas diferentes, como herramientas, priorización de urgencias, moderación de la comunidad, y organización de eventos. Busca en el sitio web del proyecto una página del "equipo", o en su repositorio para encontrar la documentación política de gobierno, para encontrar ésta documentación.
+Los proyectos más grandes pueden tener también subcomisiones o grupos de trabajo enfocados en tareas diferentes, como herramientas, priorización de urgencias, moderación de la comunidad, y organización de eventos. Busca en el sitio web del proyecto una página del "equipo", o en su repositorio para encontrar la documentación política de gobierno, para encontrar esta documentación.
 
 Un proyecto también tiene documentación. Estos archivos están normalmente listados en un nivel alto del repositorio.
 
@@ -373,7 +373,7 @@ Un proyecto que es amigable y acogedor indica que será receptivo de nuevo
 
 ## Cómo enviar una contribución
 
-Ya encontraste un proyecto que te gustaba, y estás listo para hacer una contribución. ¡Por fin! A continuación de mostramos cómo hacer que tu contribución siga por el buen camino.
+Ya encontraste un proyecto que te gustaba, y estás listo para hacer una contribución. ¡Por fin! A continuación te mostramos cómo hacer que tu contribución siga por el buen camino.
 
 ### Comunicándote de manera efectiva
 
@@ -433,9 +433,9 @@ Antes de hacer nada, haz una rápida verificación para asegurarte q
 
 Si no puedes encontrar tu idea en ningún otro lado, estás listo para dar el paso. Si el proyecto está en GitHub, es probable que lo comuniques abriendo un problema o un pull request:
 
-* **Problemas (Issues)** son como comenzar una conversación o discusión
-* **Pull requests** son para comenzar a trabajar en una solución
-* **Para una comunicación ligera,** como una explicación o una pregunta de "cómo", trata preguntando en Stack Overflow, IRC, Slack u otro canal de chat, si el proyecto tiene alguno
+* **Problemas (Issues)** son como comenzar una conversación o discusión.
+* **Pull requests** son para comenzar a trabajar en una solución.
+* **Para una comunicación ligera,** como una explicación o una pregunta de "cómo", trata preguntando en Stack Overflow, IRC, Slack u otro canal de chat, si el proyecto tiene alguno.
 
 Antes de abrir un problema o un pull request, verifica los documentos de verificación del proyecto (comúnmente es un archivo que se llama CONTRIBUTING), para ver si se necesitan incluir algo específico, puede ser que soliciten que respetes un modelo, o requerir que utilices pruebas.
 
@@ -453,9 +453,9 @@ Si quieres hacer una contribución sustancial, abre un problema para pregu
 
 Frecuentemente deberías abrir un problema en las siguientes situaciones:
 
-* Reportar un error que tú no puedes resolver
-* Discutir un tópico o idea de alto nivel (por ejemplo sobre la comunidad, la visión o políticas)
-* Proponer una nueva característica u otra idea del proyecto
+* Reportar un error que tú no puedes resolver.
+* Discutir un tópico o idea de alto nivel (por ejemplo sobre la comunidad, la visión o políticas).
+* Proponer una nueva característica u otra idea del proyecto.
 
 Consejos para comunicar los problemas:
 
@@ -467,8 +467,8 @@ Consejos para comunicar los problemas:
 
 Usualmente deberías abrir un pull request en las siguientes situaciones:
 
-* Enviar arreglos triviales (por ejemplo una corrección tipográfica, un link caído o un error obvio)
-* Comenzar a trabajar en una contribución que ya fue solicitada, o que ya discutiste en un problema
+* Enviar arreglos triviales (por ejemplo una corrección tipográfica, un link caído o un error obvio).
+* Comenzar a trabajar en una contribución que ya fue solicitada, o que ya discutiste en un problema.
 
 Un pull request no representa trabajo terminado. Usualmente es mejor abrir un pull request de forma temprana, de manera que otros puedan observar o dar retroalimentación a tu progreso. Solo márcalo como "trabajo en proceso" (WIP por sus siglas en inglés, work in progress) en la línea del tema. Siempre puedes agregar más commits después.
 

_articles/fr/starting-a-project.md

@@ -39,7 +39,7 @@ Par comparaison, un processus de source fermée serait de se rendre dans un rest
   </p>
 </aside>
 
-[Il y a plein de raisons] (https://ben.balter.com/2015/11/23/why-open-source/) pour une personne ou une organisation de vouloir ouvrir un projet. Par exemple :
+[Il y a plein de raisons](https://ben.balter.com/2015/11/23/why-open-source/) pour une personne ou une organisation de vouloir ouvrir un projet. Par exemple :
 
 * **Collaboration :** Les projets open source peuvent accepter des changements de n'importe qui dans le monde. [Exercism](https://github.com/exercism/), par exemple, est une plate-forme d'exercices de programmation avec plus de 350 contributeurs.
 

_articles/ja/best-practices.md

@@ -105,7 +105,7 @@ related:
 
 望ましくないコントリビュートをオープンのまま放置しないようにしましょう。放置すると罪悪感を感じたり親切になろうとしてしまいます。時間が経つにつれて、回答されていないイシューやプルリクエストによって、プロジェクトを進めることがストレスを伴い、恐怖を感じるものになってしまいます。
 
-受け入れるつもりのないコントリビュートはすぐに閉じてしまうのが良いです。もし既に膨大なバックログで困っているのであれば、 @steveklabnik の[イシューを効率的にトリアージする方法](http://words.steveklabnik.com/how-to-be-an-open-source-gardener)が役に立つでしょう。
+受け入れるつもりのないコントリビュートはすぐに閉じてしまうのが良いです。もし既に膨大なバックログで困っているのであれば、 @steveklabnik の[イシューを効率的にトリアージする方法](https://words.steveklabnik.com/how-to-be-an-open-source-gardener)が役に立つでしょう。
 
 また、コントリビュートを無視することはコミュニティに悪い影響を与えます。プロジェクトにコントリビュートすることは威圧感があります。特に初めてのコントリビュートであればなおさらです。たとえ、そのコントリビュートを受け入れないとしても、その人に対して受け入れない旨と感謝の気持ちを伝えましょう。それは大きな賛辞となります！
 

_articles/ja/building-community.md

@@ -54,7 +54,7 @@ related:
   <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
   これまでに（技術）イベントに参加して、知り合いが誰もおらず、周りは皆グループになって古くからの友人同士のように話しているといった経験をしたことはありませんか？（中略）オープンソースプロジェクトにコントリビュートをしたいと思っているのに、なぜ、またはどのようにそのプロジェクトが立ち上がったのかがわからないという状況を想像してみて下さい。
   <p markdown="1" class="pquote-credit">
-— @janl, ["Sustainable Open Source"](http://writing.jan.io/2015/11/20/sustainable-open-source.html)
+— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
   </p>
 </aside>
 
@@ -250,7 +250,7 @@ README は[単なる手順書以上の存在です](../starting-a-project/#readm
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
   強引にならずに議論を実利的なものに導いていくのはある種の技術です。単に無駄な時間を使わないよう忠告したり、建設的な内容がない限り書かないでほしいとお願いするだけではうまくいきません。 (中略) そうする代わりに、議論を進める条件を提案する必要があります：例えば指針を与えたり、あなたが望む結論に導くための道筋を提示したりといったことです。ただ、あなたが行動を指示しているように聞こえないよう気をつける必要があります。
   <p markdown="1" class="pquote-credit">
-— @kfogel, [_Producing OSS_](http://producingoss.com/en/producingoss.html#common-pitfalls)
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
   </p>
 </aside>
 

_articles/ja/how-to-contribute.md

@@ -368,7 +368,7 @@ master ブランチのコミットアクティビティをみてみましょう
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
   長いスレッドを見つけたら常に、スレッドの中で遅れてやってくるコア開発者の返答を確認してみましょう。彼らは建設的にまとめて、丁寧な姿勢を保ちつつもスレッドを結論に仕向けるべく一歩を踏み出していますか？もし罵り合いが多くあるのであれば、それはエネルギーが開発に向けられる代わりに議論に使われている兆候です。
   <p markdown="1" class="pquote-credit">
-— @kfogel, [_Producing OSS_](http://producingoss.com/en/evaluating-oss-projects.html)
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
   </p>
 </aside>