diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index 29808f19840..a16f77db2d2 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -1,170 +1,170 @@
 ---
 lang: de
-untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+untranslated: false
+title: Balance für Open-Source-Maintainer halten
+description: Tipps zur Selbsthilfe und zur Vermeidung von Burnout als Maintainer.
 class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+Wenn ein Open-Source-Projekt immer beliebter wird, ist es wichtig, sich klare Grenzen zu setzen, um die Balance zu halten, damit man auf lange Sicht motiviert und produktiv bleibt. 
 
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+Um Einblicke in die Erfahrungen von Maintainern und ihre Strategien, eine Balance zu finden, zu gewinnen, haben wir einen Workshop mit 40 Mitgliedern der <a href="http://maintainers.github.com/">Maintainer-Community</a> durchgeführt. So konnten wir aus erster Hand von ihren Erfahrungen mit Burnout in der Open-Source-Branche und den Praktiken lernen, die ihnen geholfen haben, bei ihrer Arbeit eine Balance zu halten. An dieser Stelle kommt das Konzept der persönlichen Ökologie ins Spiel.
 
-So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+Was also ist persönliche Ökologie? <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">Laut dem Rockwood Leadership Institute</a> geht es darum, "<strong>das Gleichgewicht, das Tempo und die Effizienz aufrechtzuerhalten, um unsere Energie ein Leben lang zu erhalten</strong>." Dies gab unseren Gesprächen einen Rahmen und half den Maintainern, ihre Beiträge als Teil eines größeren Ökosystems zu erkennen, das sich im Laufe der Zeit weiterentwickelt. Burnout, ein Syndrom, das aus chronischem Stress am Arbeitsplatz resultiert, wie [von der WHO definiert](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), ist unter Maintainern keine Seltenheit. Dies führt oft zu einem Motivationsverlust, einer Unfähigkeit, sich zu konzentrieren, und einem Mangel an Empathie für die Mitwirkenden und die Community, mit der man arbeitet.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
-  I was unable to focus or start on a task. I had a lack of empathy for users.
+  Ich war nicht in der Lage, mich zu konzentrieren oder mit einer Aufgabe zu beginnen. Mir fehlte es an Empathie für die Benutzer.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, Maintainer des Owncast Live-Streaming-Servers, über die Folgen von Burnout auf seine Arbeit mit Open Source
   </p>
 </aside>
 
-By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+Indem sie sich mit dem Konzept der persönlichen Ökologie vertraut machen, können Maintainer Burnout vorbeugen, der eigenen Gesundheit Priorität einräumen und ein Gefühl der Ausgeglichenheit bewahren, um ihre Bestleistung zu erbringen.
 
-## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+## Tipps zur Selbsthilfe und zur Vorbeugung von Burnout als Maintainer:
 
-### Identify your motivations for working in open source
+### Erkennen Sie Ihre Motivation für Open-Source-Arbeit
 
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+Nehmen Sie sich Zeit, darüber nachzudenken, was Sie an der Pflege von Open-Source-Projekten reizt. Wenn Sie Ihre Motivationen verstehen, können Sie die Arbeit so priorisieren, dass Sie engagiert und bereit für neue Herausforderungen bleiben. Ob es das positive Feedback der Benutzer ist, die Freude an der Zusammenarbeit und am Austausch mit der Gemeinschaft oder die Befriedigung, in den Code einzutauchen - das Erkennen Ihrer Motivationen kann Ihnen helfen, Ihren Fokus zu richten.
 
-### Reflect on what causes you to get out of balance and stressed out
+### Überlegen Sie, was Sie aus dem Gleichgewicht und in Stress bringt
 
-It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+Es ist wichtig zu verstehen, was die Ursachen für Burnout sind. Hier sind ein paar gemeinsame Ursachen, die wir bei Open-Source-Betreuern festgestellt haben:
 
-* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+* **Mangel an positivem Feedback:** Nutzer sind viel eher bereit, Beschwerden zu äußern, wenn sie ein Problem haben. Wenn alles gut läuft, schweigen sie eher. Es kann entmutigend sein, eine wachsende Liste von Problemen zu sehen, ohne positives Feedback, das zeigt, wie Ihre Beiträge etwas bewirken.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
-  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  Manchmal fühlt es sich so an, als würde man ins Leere schreien, und ich finde, dass mich dieses Feedback wirklich anspornt. Wir haben viele glückliche, aber stille Nutzer.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+— <a href="https://github.com/thisisnic">@thisisnic</a>, Maintainer von Apache Arrow
   </p>
 </aside>
 
-* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+* **Nicht "Nein" sagen:** Es kann leicht passieren, dass man bei einem Open-Source-Projekt mehr Verantwortung übernimmt, als man sollte. Ob von Nutzern, Mitwirkenden oder anderen Betreuern - wir können nicht immer ihren Erwartungen gerecht werden.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
-  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  Ich stellte fest, dass ich mehr als eine Aufgabe übernehmen und die Arbeit mehrerer Personen erledigen musste, wie es bei FOSS üblich ist.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, Maintainer von Termux, über die Ursachen von Burnout bei seiner Arbeit
   </p>
 </aside>
 
-* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+* **Alleine arbeiten:** Ein Maintainer zu sein, kann unglaublich einsam sein. Selbst wenn Sie mit einer Gruppe von Betreuern zusammenarbeiten, war es in den letzten Jahren schwierig, sich persönlich mit zerstreuten Teams zu treffen.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
- Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+ Vor allem seit Corona und der Arbeit von zu Hause aus ist es schwieriger, nie jemanden zu sehen oder mit jemandem zu sprechen.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, Maintainer des Owncast Live-Streaming-Servers, über die Folgen von Burnout auf seine Open-Source-Arbeit
   </p>
 </aside>
 
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+* **Nicht genug Zeit oder Ressourcen:** Dies gilt insbesondere für freiwillige Maintainer, die ihre Freizeit für die Arbeit an einem Projekt opfern müssen.
 
 <aside markdown="1" class="pquote">
-  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  Ich hätte gerne mehr finanzielle Unterstützung, sodass ich mich auf die Open-Source-Arbeit konzentrieren kann, ohne mein Erspartes aufzubrauchen und zu wissen, dass ich später eine Menge Auftragsarbeiten erledigen muss, um das zu kompensieren.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— Open-Source-Maintainer
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Unterschiedliche Forderungen:**  Open Source ist voll von Gruppen mit unterschiedlichen Motivationen, die schwer zu durchschauen sind. Wenn Sie für Ihre Arbeit an Open Source bezahlt werden, können die Interessen Ihres Arbeitgebers manchmal mit denen der Community kollidieren.
 
 <aside markdown="1" class="pquote">
-  With paid open source, conflict between employer's focus and what's best for the community
+  Bei kommerziellen Produkten mit offenem Quellcode besteht ein Konflikt zwischen den Interessen des Arbeitgebers und dem, was das Beste für die Gemeinschaft ist
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— Open-Source-Maintainer
   </p>
 </aside>
 
-### Watch out for signs of burnout
+### Halte Ausschau nach Zeichen für Burnout
 
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+Können Sie Ihr Tempo 10 Wochen lang beibehalten? 10 Monate? 10 Jahre?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+Es gibt Tools wie die [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) von [@shaunagm](https://github.com/shaunagm) und Mozillas [Personal Ecology Self-Assessment Kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), die Ihnen dabei helfen können, Ihr aktuelles Tempo zu reflektieren und zu sehen, ob Sie Anpassungen vornehmen können. Einige Betreuer verwenden auch Wearables, um Messwerte wie Schlafqualität und Herzfrequenzvariabilität (die beide mit Stress in Verbindung stehen) zu verfolgen.
 
 <aside markdown="1" class="pquote">
- I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+ Ich bin ein großer Befürworter von guten Wearables. Mit der Wissenschaft dahinter kann man verstehen, was man hätte besser machen können und wie man seine Ziele optimal erreichen kann.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— Open-Source-Maintainer
   </p>
 </aside>
 
-### What would you need to continue sustaining yourself and your community?
+### Was brauchen Sie, um sich und Ihre Gemeinschaft weiterhin zu erhalten?
 
-This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+Dies wird für jeden Betreuer unterschiedlich sein und sich je nach Lebensphase und anderen äußeren Faktoren ändern. Aber hier sind ein paar Aspekte, die wir gehört haben:
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **Vertrauen Sie der Community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
 
-  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+  Sie können auch nach Möglichkeiten suchen, mit der Nutzergemeinde in Kontakt zu treten, damit Sie regelmäßig Feedback erhalten und die Auswirkungen Ihrer Open-Source-Arbeit verstehen.
 
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **Finanzierung erforschen:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
- I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+ Ich war vor einiger Zeit in einem Podcast und wir sprachen über die Instandhaltung von Open Source und Nachhaltigkeit. Ich fand, dass selbst eine kleine Anzahl von Leuten, die meine Arbeit auf GitHub unterstützen, mir geholfen hat, eine schnelle Entscheidung zu treffen, nicht vor einem Spiel zu sitzen, sondern stattdessen eine kleine Sache mit Open Source zu machen.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+— <a href="https://github.com/mansona">@mansona</a>, Maintainer von EmberJS
   </p>
 </aside>
 
-* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+* **Tools einsetzen:** Entdecken Sie Tools wie [GitHub Copilot](https://github.com/features/copilot/) und [GitHub Actions](https://github.com/features/actions), um alltägliche Aufgaben zu automatisieren und Zeit für sinnvollere Beiträge zu gewinnen.
 
 <aside markdown="1" class="pquote">
- Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+ Verwenden Sie [Copilot](https://github.com/features/copilot/) für die langweiligen Dinge - machen Sie die Dinge, die Ihnen Spaß machen
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— Open-Source-Maintainer
   </p>
 </aside>
 
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+* **Ausruhen und regenerieren:** Nehmen Sie sich Zeit für Ihre Hobbys und Interessen außerhalb von Open Source. Nehmen Sie sich am Wochenende frei, um sich zu entspannen und zu erholen - und stellen Sie Ihren [GitHub-Status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) so ein, dass er Ihre Verfügbarkeit widerspiegelt! Erholsamer Schlaf kann einen großen Unterschied machen, wenn es darum geht, Ihre Leistung langfristig aufrechtzuerhalten.
 
-  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+  Wenn Ihnen bestimmte Aspekte Ihres Projekts besonders viel Spaß machen, versuchen Sie, Ihre Arbeit so zu strukturieren, dass Sie sie während des Tages erleben können.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+ Ich finde mehr Zeit, um "kreative Momente" in den Tag zu bringen, als dass ich versuche, am Abend abzuschalten.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+— <a href="https://github.com/danielroe">@danielroe</a>, Maintainer von Nuxt
   </p>
 </aside>
 
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **Grenzen setzen:** Sie können nicht zu jeder Anfrage Ja sagen. Das kann so einfach sein, wie zu sagen: "Das kann ich im Moment nicht machen und ich habe auch nicht vor, es in Zukunft zu machen", oder in der README aufzulisten, was Sie gerne machen würden und was nicht. Sie könnten zum Beispiel sagen: "Ich führe nur PRs zusammen, die eine klare Begründung haben, warum sie gemacht wurden", oder "Ich überprüfe Probleme nur abwechselnd donnerstags von 18 - 19 Uhr". Das setzt Erwartungen für andere und gibt Ihnen etwas, auf das Sie zu anderen Zeiten verweisen können, um Forderungen von Mitwirkenden oder Benutzern nach Ihrer Zeit zu deeskalieren.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+Um auf diesen Säulen wirklich vertrauen zu können, darf man nicht zu jeder Anfrage Ja sagen. Wenn Sie das tun, halten Sie sich weder beruflich noch persönlich an Grenzen und werden kein verlässlicher Mitarbeiter sein.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, Maintainer von Homebrew zum [Nein-Sagen](https://mikemcquaid.com/saying-no/)
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+  Lernen Sie, giftiges Verhalten und negative Interaktionen konsequent zu unterbinden. Es ist in Ordnung, keine Energie für Dinge aufzuwenden, die Ihnen egal sind.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
-My software is gratis, but my time and attention is not.
+Meine Software ist gratis, aber meine Zeit und Aufmerksamkeit sind es nicht.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, Maintainer von Leaflet
   </p>
 </aside>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+Es ist kein Geheimnis, dass die Entwicklung von Open-Source-Projekten auch ihre Schattenseiten hat, und eine davon ist, dass man manchmal mit undankbaren, überheblichen oder regelrecht toxischen Leuten interagieren muss. Mit zunehmender Popularität eines Projekts steigt auch die Häufigkeit dieser Interaktion, was die Belastung der Maintainer erhöht und möglicherweise zu einem bedeutenden Risikofaktor für ein Burnout der Maintainer wird.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— <a href="https://github.com/foosel">@foosel</a>, Maintainer von Octoprint zu [Umgang mit toxischen Leuten](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
 </aside>
 
-Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+Denken Sie daran, dass persönliche Ökologie eine fortlaufende Praxis ist, die sich im Laufe Ihrer Open-Source-Reise weiterentwickeln wird. Indem Sie Ihre Selbstfürsorge in den Vordergrund stellen und ein Gleichgewicht aufrechterhalten, können Sie einen effektiven und nachhaltigen Beitrag zur Open-Source-Gemeinschaft leisten und sowohl Ihr Wohlbefinden als auch den Erfolg Ihrer Projekte auf lange Sicht sicherstellen.
 
-## Additional Resources
+## Weitere Artikel
 
 * [Maintainer Community](http://maintainers.github.com/)
 * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
@@ -177,11 +177,11 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
 * Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
 
-## Contributors
+## Mitwirkende
 
-Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+Vielen Dank an alle Maintainer, die uns ihre Erfahrungen und Tipps für diesen Leitfaden zur Verfügung gestellt haben!
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+Dieser Leitfaden wurde von [@abbycabs](https://github.com/abbycabs) geschrieben mit Beiträgen von: 
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
@@ -218,4 +218,5 @@ This guide was written by [@abbycabs](https://github.com/abbycabs) with contribu
 [@thisisnic](https://github.com/thisisnic)
 [@tudoramariei](https://github.com/tudoramariei)
 [@UlisesGascon](https://github.com/UlisesGascon)
-[@waldyrious](https://github.com/waldyrious) + many others!
+[@waldyrious](https://github.com/waldyrious)
+[@WebSnke](https://github.com/WebSnke) + vielen anderen!
diff --git a/_articles/legal.md b/_articles/legal.md
index 8adc3897659..b124e1e4477 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -12,7 +12,7 @@ related:
 
 ## Understanding the legal implications of open source
 
-Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, with this guide you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).)
 
 ## Why do people care so much about the legal side of open source?
 
@@ -20,9 +20,9 @@ Glad you asked! When you make a creative work (such as writing, graphics, or cod
 
 In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
 
-Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions.
+Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly give these permissions with a license.
 
-If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you.
+These rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions.
 
 Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
 
@@ -40,7 +40,7 @@ If you want others to use, distribute, modify, or contribute back to your projec
 
 You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
 
-[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/).
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are [popular open source licenses](https://innovationgraph.github.com/global-metrics/licenses), but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/).
 
 When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/).
 
@@ -54,21 +54,23 @@ When you create a new project on GitHub, you'll be [asked to add a license](http
 
 ## Which open source license is appropriate for my project?
 
-If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+It's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/) if you're starting with a blank slate. It's short, easily understood, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
 
 Otherwise, picking the right open source license for your project depends on your objectives.
 
-Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
+Your project very likely has (or will have) **dependencies**, each of which will have its own open source license with terms you have to respect. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm).
 
-On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
+Dependencies with **permissive licenses** like [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause) allow you to license your project however you want.
 
+Dependencies with **copyleft licenses** require closer attention. Including any library with a "strong" copyleft license like the [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), or [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) requires you to choose an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) for your project. Libraries with a "limited" or "weak" copyleft license like the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) can be included in projects with any license, provided you follow the [additional rules](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) they specify.
+ 
 You may also want to consider the **communities** you hope will use and contribute to your project:
 
 * **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
-* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
+* **Do you want your project to appeal to large businesses?** A large business may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) (and them) covered.
 * **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
 
-Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+Your **company** may have policies for open source project licensing. Some companies require your projects to bear a permissive license to permit integration with the company's proprietary products. Other policies enforce a strong copyleft license and an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) so only your company can use the project in closed source software. Organizations may also have certain standards, social responsibility goals, or transparency needs which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know) for guidance.
 
 When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
 
@@ -82,9 +84,9 @@ For example, as your project grows it adds dependencies or users, or your compan
 
 **Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
 
-**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? [People who have commits in your project](https://github.com/thehale/git-authorship) is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
 
-Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+Alternatively, you can have contributors pre-approve certain license changes via an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)). This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
 
 ## Does my project need an additional contributor agreement?
 
@@ -120,11 +122,11 @@ For better or worse, consider letting them know even if it's a personal project.
 
 **If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
 
-* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses ([see above](#which-open-source-license-is-appropriate-for-my-project)). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
 
 * **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
 
-* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above).
+* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement ([see above](#which-open-source-license-is-appropriate-for-my-project)).
 
 * **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
 
diff --git a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
index df51babccb0..e4996e13c30 100644
--- a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
@@ -1,187 +1,187 @@
 ---
 lang: zh-hans
 untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+title: 保持开源维护者的平衡
+description: 作为维护者的自我护理和避免倦怠的技巧。
 class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+当一个开源项目越来越受欢迎时，设定清晰的边界来帮助您长时间保持活力和生产力就变得尤为重要了。
 
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+为了深入了解维护者的经验及他们如何找到工作平衡，我们与<a href="http://maintainers.github.com/">维护者社区</a>的 40 名成员举办了一个 workshop。通过这样的方式，我们得以学习到他们在开源领域所经历的疲劳过度的第一手情况，以及他们采取了哪些实践来在工作中维持平衡。这正是"个人生态学"概念得以应用的场景。
 
-So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+那么，个人生态学是什么？根据 <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">Rockwood Leadership Institute 的描述</a>，它是"<strong>在我们的一生中，维持平衡、节奏和效率以保持能量</strong>”。这种观点为我们的交流提供了一个结构，帮助维护者意识到随时间发展，他们的行为和贡献是一个更大的生态系统中的组成部分。根据[世卫组织的定义](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281)，由长时间的工作压力引起的综合症状，即"疲劳过度"，在维护者中并不罕见。这常常会导致失去工作动力、无法集中精力，以及对与之合作的贡献者和社区感到缺乏同情和理解。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
-  I was unable to focus or start on a task. I had a lack of empathy for users.
+  我无法集中注意力或开始任务。我对用户缺乏同情心。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>，Owncast 直播服务的维护者，谈到疲劳对他的开源工作的影响
   </p>
 </aside>
 
-By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+通过理解个人生态学的理念，维护者可以主动避免疲劳，把自我护理放在首位，并保持心态平和，从而更好地工作。
 
-## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+## 作为维护者的自我护理和避免疲劳的提示：
 
-### Identify your motivations for working in open source
+### 确定您参与开源工作的动机
 
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+花时间思考哪些开源维护任务能激发您的热情。明白自己的驱动力可以帮您更有针对性地安排工作，保持热情并随时迎接新挑战。不论是用户的正面反馈、与社区的互动乐趣，还是深入探索代码带来的成就感，了解这些驱动力都能帮助您更好地集中精力。
 
-### Reflect on what causes you to get out of balance and stressed out
+### 反思什么使您失去平衡并感到压力
 
-It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+知道哪些因素导致我们感到疲倦是非常关键的。以下是在开源维护者中常见的一些情况：
 
-* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+* **缺乏积极的反馈：** 用户在遇到问题时更容易给出反馈。而当一切正常时，他们往往不会说什么。看到问题列表不断增长，而缺乏正面反馈来展示您的贡献所带来的改变，这可能会让人感到挫败。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
-  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  有时，我觉得自己有点像在虚空中大喊大叫，但我发现反馈意见真的让我充满活力。我们有很多快乐但安静的用户。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+— <a href="https://github.com/thisisnic">@thisisnic</a>，Apache Arrow 的维护者
   </p>
 </aside>
 
-* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+* **不说'不'：** 在开源项目中，很容易承担超过自己能力范围的责任。不论是来自用户、贡献者还是其他维护者，我们不能始终满足每个人的期望。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
-  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  我发现自己承担的工作超出了一个人的职责范围，不得不像 FOSS 中常见的那样，完成多人的工作。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>，Termux 的维护者，谈论他们工作中导致疲劳的原因
   </p>
 </aside>
 
-* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+* **独自工作：** 作为维护者可能会感到很孤单。即使你与一群维护者合作，过去几年也很难召集分布在各地的团队。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
- Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+ 特别是自从 COVID 和居家办公后，再也见不到人或和人说话就更难了。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>，Owncast 直播服务器的维护者，谈论疲劳对他的开源工作的影响
   </p>
 </aside>
 
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+* **时间或资源不足：** 对于那些不得不牺牲自己休息时间来参与项目的志愿维护者来说，这尤其是真实的。
 
 <aside markdown="1" class="pquote">
-  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  [我希望]能得到更多的经济支持，这样我可以全心投入到开源工作中，而不是消耗掉自己的储蓄，然后担心未来需要做大量的工作来补偿这一损失。
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— 开源维护者
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **需求冲突：** 开源社区有很多出于不同目的而参与的团队，这有时会难以处理。如果您是被雇来进行开源工作的，那么您的雇主的利益有时与社区的利益可能不会完全一致。
 
 <aside markdown="1" class="pquote">
-  With paid open source, conflict between employer's focus and what's best for the community
+  在有偿的开源工作中，雇主的关注点和对社区最有益的事物之间可能会存在矛盾。
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— 开源维护者
   </p>
 </aside>
 
-### Watch out for signs of burnout
+### 注意疲劳的迹象
 
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+这样的节奏你能保持多久？10周？10个月？还是10年？
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+有像 [@shaunagm](https://github.com/shaunagm) 的 [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) 和 Mozilla 的[个人生态自评工具包](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw)这样的工具可以帮助你反思自己现在的工作节奏，看是否需要进行某些调整。一些维护者还利用可穿戴设备来监测睡眠质量和心率变异性等与压力有关的指标。
 
 <aside markdown="1" class="pquote">
- I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+ 我深信好的可穿戴设备的作用。有了其背后的科学依据，你可以了解如何更好地调整自己，达到完成任务的最佳状态。
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— 开源维护者
   </p>
 </aside>
 
-### What would you need to continue sustaining yourself and your community?
+### 您需要什么来继续支撑自己和您的社区？
 
-This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+对每位维护者而言，这都会有所区别，并且会随着您的生活阶段和其他外部因素发生变化。但以下是我们收到的一些共同点：
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **依赖社区：** 分配任务和寻找贡献者可以帮助减轻你的负担。对一个项目而言，有多个协作者能让你放心休息。与其他维护者以及更广大的社区，如 [Maintainer Community](http://maintainers.github.com/) 建立联系，这对于获得同行的支持和学习都是宝贵的资源。
 
-  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+  您还可以探索与用户社区的交互方式，这样可以定期收到反馈，了解您在开源工作中所做的贡献的影响。
 
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **寻找资金：** 不管您是想找点小钱买披萨，还是计划全职投身开源，都有众多资源可供参考！首先，可以考虑开通 [GitHub Sponsors](https://github.com/sponsors) 让其他人赞助您的开源项目。如果您打算全职转型，可以申请下一期的 [GitHub Accelerator](http://accelerator.github.com/)。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
- I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+我曾参与一个播客，其中我们谈到了开源维护和可持续性。我发现，尽管只有少数人支持我在 GitHub 的工作，但这也帮助我做出了迅速的选择，放下游戏前端的工作转而去做一些小的开源贡献。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+— <a href="https://github.com/mansona">@mansona</a>，EmberJS 的维护者
   </p>
 </aside>
 
-* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+* **使用工具：** 考虑使用像 [GitHub Copilot](https://github.com/features/copilot/) 和 [GitHub Actions](https://github.com/features/actions) 这样的工具，自动化常规任务，从而为更有价值的工作腾出时间。
 
 <aside markdown="1" class="pquote">
- Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+ 使用 [Copilot](https://github.com/features/copilot/) 来处理无聊的事情 - 做有趣的事情
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— 开源维护者
   </p>
 </aside>
 
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+* **休息和充电：** 留出时间享受开源之外的爱好和兴趣。利用周末休息和充电，并调整您的 [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) 来显示您是否在线！良好的睡眠对于长期保持工作热情和效率至关重要。
 
-  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+  如果您发现项目中某些部分特别令人享受，试着调整您的工作，这样您每天都可以体验到这种愉悦。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+我发现在一天当中找到更多机会去散播"创意时刻"比起在晚上尝试放松更为有益。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+— <a href="https://github.com/danielroe">@danielroe</a>，Nuxt 的维护者
   </p>
 </aside>
 
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **设定界限：** 您不能对每个请求都回应"好"。您可以简单地回答："我现在做不到，而且未来可能也不会这么做。"或者在 README 中明确列出您愿意做和不愿意做的事情。例如，您可以写："我只会合并那些清晰解释了为何创建的 PR。”或者，"我只在每两周的星期四的6-7点审查问题。”这样可以为他人设定预期，并在其他时间为您提供一个可以参考的依据，从而减少贡献者或用户对您时间的要求。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+为了在这些方面真正赢得他人的信任，你不能是一个对每个请求都说"是"的人。这样做意味着你没有设定职业和个人的界限，也难以成为一个可靠的合作伙伴。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>，Homebrew 的维护者在 [Saying No](https://mikemcquaid.com/saying-no/) 上
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+学会坚决制止有毒的行为和消极的互动。不对你不在乎的事情投入精力是完全可以的。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
-My software is gratis, but my time and attention is not.
+我的软件是免费的，但我的时间和精力不是。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>，Leaflet 的维护者
   </p>
 </aside>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+开源代码维护工作有其阴暗面，这已经不是什么秘密了，其中之一就是有时不得不与那些忘恩负义、有权有势或完全有毒的人打交道。随着项目受欢迎程度的提高，这种互动的频率也会增加，从而加重维护者的负担，并可能成为维护者倦怠的一个重要风险因素。
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— <a href="https://github.com/foosel">@foosel</a>，Octoprint 的维护者，在[如何应对有毒的人](https://www.youtube.com/watch?v=7lIpP3GEyXs)上
   </p>
 </aside>
 
-Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+请记住，个人生态是随着您在开源之旅中不断前行而演变的持续实践。通过把自我护理和保持平衡放在首位，您可以为开源社区提供持续有效的贡献，确保自己的健康和项目的长久发展。
 
-## Additional Resources
+## 额外资源
 
 * [Maintainer Community](http://maintainers.github.com/)
-* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
-* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
-* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [开源的社会契约](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [如何应对有毒的人](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
-* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
-* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [个人生态自评工具包](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood领导艺术](https://rockwoodleadership.org/art-of-leadership/)
+* [说"不"](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
 * [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
-* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+* Workshop 议程改编自 [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) 系列活动
 
-## Contributors
+## 贡献者
 
-Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+非常感谢所有与我们分享经验和技巧的维护者！
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+本指南是由[@abbycabs](https://github.com/abbycabs)编写的，由以下人员贡献：
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
diff --git a/_data/locales/de.yml b/_data/locales/de.yml
index d2891744842..0997210c73a 100644
--- a/_data/locales/de.yml
+++ b/_data/locales/de.yml
@@ -28,4 +28,4 @@ de:
       # Label für das Herz-Octicon
       love_label: love
       # Label für das Octicon der Mitwirkenden
-      friends_label: friends
+      friends_label: Freunden