Minor fix to align Host and Core team references (#599)

* 📝 Update host and core team references

* 🇩🇪 Traslate host and core team references

* 🇪🇸 Traslate host and core team references

* 🇫🇷 Traslate host and core team references

* 🇮🇹 Traslate host and core team references

* 🇯🇵 Traslate host and core team references

* 🇧🇷 Traslate host and core team references

* 🇷🇺 Traslate host and core team references

* 🇨🇳 Traslate host and core team references

* Update introduction/03-how-works.asciidoc

Co-authored-by: rrrutledge <[email protected]>

* ✏️ (french): Fix translate into French

* Update introduction/pt-br/03-how-works-pt-br.asciidoc

Co-authored-by: Arthur Fücher <[email protected]>

* Update introduction/pt-br/05-principles-pt-br.asciidoc

Co-authored-by: Arthur Fücher <[email protected]>

* Update introduction/pt-br/07-faq-pt-br.asciidoc

Co-authored-by: Arthur Fücher <[email protected]>

* ✏️ (lang): Fix Chinese translations

* Update introduction/ja/03-how-works-ja.asciidoc

Co-authored-by: Leona Matsumoto <[email protected]>

* Update introduction/ja/05-principles-ja.asciidoc

Co-authored-by: Leona Matsumoto <[email protected]>

---------

Co-authored-by: rrrutledge <[email protected]>
Co-authored-by: Arthur Fücher <[email protected]>
Co-authored-by: Leona Matsumoto <[email protected]>

Author: 4 people

README.md

@@ -14,7 +14,7 @@ Currently, the four sections to the learning path are:
   1. [Contributor](http://innersourcecommons.org/learn/learning-path/contributor/)
   1. [Product Owner](http://innersourcecommons.org/learn/learning-path/product-owner/)
   1. [Project Leader](https://innersourcecommons.org/learn/learning-path/project-leader/)
- 
+
 There is also the [workbook](workbook/), a collection of questions and answers on based on the videos and articles for people to check their knowledge against after consuming the material.
 
 New sections and segments may be added at any time via the [contribution] process.
@@ -25,7 +25,7 @@ The InnerSource Learning Path is produced via the [InnerSource Commons] communit
 We coordinate our work in the [#learning-path] _Slack_ channel.
 We track our tasks and discuss their status openly using our GitHub project [Kanban board].
 
-Typically, a card bundles tasks about one artifact (e.g. written articles accompanying one learning path section) or small milestones (e.g. finishing the post production of one section). 
+Typically, a card bundles tasks about one artifact (e.g. written articles accompanying one learning path section) or small milestones (e.g. finishing the post production of one section).
 You can infer whether a task is currently actively developed or under review based on the card's column in the [Kanban board].
 
 ## Trusted Committers
@@ -67,7 +67,7 @@ workbook/0n-section-name.asciidoc // Contains the part of the workbook matching
 After material is finished the scripts will be used to film videos.
 Each video should be about 5min in length.
 Each article should be about a page long.
-The idea is that a person could receive a link to an article or video and watch or read it without having to set aside time in advance to do so. 
+The idea is that a person could receive a link to an article or video and watch or read it without having to set aside time in advance to do so.
 Videos, articles, and workbooks will be published at _learning.oreilly.com_ and also at _innersourcecommons.org_.
 
 ## How to Get Involved

introduction/03-how-works.asciidoc

@@ -43,4 +43,5 @@ More engineering time stays focused on producing code that solves company proble
 
 === Additional Resources
 
+* The host team can be represented by the https://patterns.innersourcecommons.org/p/core-team[Core Team] pattern.
 * The https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer] pattern.

introduction/05-principles.asciidoc

@@ -41,7 +41,7 @@ This means that guest teams should be able to have an understanding of:
 * Decision making of the host team
 
 When possible, the above should be communicated clearly and in detail, from teams' internal definitions of items to special-case scenarios specific to the project.
-This communication should be done in a manner that can be easily queried and understood to those that are not part of the core team.
+This communication should be done in a manner that can be easily queried and understood to those that are not part of the host team.
 
 === Prioritized Mentorship
 

introduction/07-faq.asciidoc

@@ -24,7 +24,7 @@ It depends on how far you're going. You'll probably be going a lot further than
 image::https://user-images.githubusercontent.com/9609562/151901209-52b3468b-dedd-4319-9ca3-38b6b2bcfaf5.png[If you want to go fast, go alone. If you want to go far, go together]
 
 === Will we just be reviewing PRs all day every day?
-If so then your core team is understaffed. A healthy team is staffed so that there is time for assisting contributors and making core contributions yourself.
+If so then your https://patterns.innersourcecommons.org/p/core-team[core team] is understaffed. A healthy team is staffed so that there is time for assisting contributors and making core contributions yourself.
 
 You can mitigate this by setting expectation, potentially via SLAs. If contributors expect PR reviews within an hour, maybe you will be stuck reviewing PRs all the time, but if you set an SLA of 1 day or 1 week, this won't be the case.
 

introduction/de/03-how-works-de.asciidoc

@@ -28,13 +28,13 @@ Bei kleinen, einfacheren Projekten füllt oft eine einzelne Person _sowohl_ die
 Basierend auf diesen Rollen können wir nun den InnerSource-Prozesses grob skizzieren.
 
 * Das Gastteam, beziehungsweise konkret ein Mitglied des Gastteams, fragt eine Funktion vom Host-Team an.
-* Der Product Owner stellt sicher, dass User Stories entsprechend dem Feature Request erstellt werden: Entweder vom Guest Team oder vom Host Team. 
+* Der Product Owner stellt sicher, dass User Stories entsprechend dem Feature Request erstellt werden: Entweder vom Guest Team oder vom Host Team.
 Diese Userstories beschreiben das gewünschte Feature so wie es sich das Gastteam vorstellt.
 Die User Stories enthalten auch all jene Details, auf die das Host Team vor Annahme der Änderung Wert legt.
 Beispiele für solche Details sind Besonderheiten in der Architektur, Coding Conventions, die Verwendung spezifischer Bibliotheken, Contracts hinsichtlich Daten usw.
 * Unterstützt vom Trusted Committer, sendet der Contributor den Pull-Request, um das angefragte Feature zu implementieren.
 
-Zu beachten ist, dass bei diesen Schritten kein bestimmter Prozess für Koordination oder Priorisierung der Teams vorrausgesetzt wird. 
+Zu beachten ist, dass bei diesen Schritten kein bestimmter Prozess für Koordination oder Priorisierung der Teams vorrausgesetzt wird.
 InnerSource geht davon aus, dass Teams bereits über vorhandene Organisationsmethoden verfügen, und bietet einen Rahmen für die Zusammenarbeit, wenn ein Gastteam Code zu einem Project beitragen möchte.
 
 Dieser Weg der Zusammenarbeit birgt Vorteile für das Gastteam. Es erhält die Funktionalität, die es benötigt zum rechten Zeitpunkt und ohne die Verpflichtung, die langfristige Wartung der Lösung zu übernehmen.
@@ -44,4 +44,5 @@ In letzter Konsequenz fließt mehr Zeit in Code, der die eigentlichen Unternehme
 
 === Zusätzliche Ressourcen
 
+* Das Hostteam wird normalerweise durch das Muster https://patterns.innersourcecommons.org/p/core-team[Core Team] dargestellt.
 * Die Mustervorlage https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer].

introduction/de/05-principles-de.asciidoc

@@ -41,7 +41,7 @@ Dies bedeutet, dass Gastteams in der Lage sein sollten, folgendes zu verstehen:
 * Entscheidungsfindungsprozess des Hostteams
 
 Wenn möglich, sollte das obige klar und detailliert kommuniziert werden, von den internen Definitionen der verbleibenden Arbeit bis hin zu projektspezifischen Spezialszenarien.
-Diese Kommunikation sollte auf eine Weise erfolgen, sodass die Information für diejenigen, die nicht Teil des Kernteams sind, leicht gefunden and nachvollzogen werden kann.
+Diese Kommunikation sollte so erfolgen, dass sie für Personen, die nicht zum Gastgeberteam gehören, leicht abgefragt und verstanden werden kann.
 
 === Priorisierte Betreuung
 
@@ -54,7 +54,7 @@ Es ist wichtig, dass Mentoring für potentielle Contributoren vom Hostteam prior
 Das Hostteam sollte sich bemühen, sich ausreichend Zeit für die Betreuung der Contributor des Gastteams zu nehmen - ganz speziell zu dem Zeitpunkt zu dem der Contributor es benötigt - und nicht, wenn es für das Hostteam bequem ist.
 Manchmal kann es für Entwickler im Hostteam ein Kulturwandel sein, Zeit zu investieren um anderen beim Schreiben von Quellecode zu helfen, anstatt selbst zu entwickeln.
 Diese Art des Mentorings ist sowohl für den einzelnen Mitarbeiter des Gastteams als auch für den Gastgeber wertvoll, und es lohnt sich den Aufwand zu betreiben.
-Es erweist sich auf lange Sicht als vorteilhaft für beide Seiten. 
+Es erweist sich auf lange Sicht als vorteilhaft für beide Seiten.
 Durch die Verbesserung des Quellcodes bildet oder verbessert der Mitarbeiter die Beziehungen innerhalb einer Organisation, die sonst möglicherweise nicht existiert hätten.
 Open Source erkennt diesen Punkt sofort und betrachtet es als eine Ehre, den Status eines Trusted Committers für ein Projekt zu erreichen.
 

introduction/es/03-how-works-es.asciidoc

@@ -38,4 +38,5 @@ Finalmente, se invierte más tiempo de ingeniería en producir código que resue
 
 === Recursos adicionales
 
+* El equipo anfitrión generalmente está representado por el patrón https://patterns.innersourcecommons.org/p/core-team[Core Team].
 * El patrón del https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/trusted-committer.md[Trusted Committer].

introduction/es/05-principles-es.asciidoc

@@ -42,8 +42,7 @@ Esto significa que el equipo contribuidor debe entender:
 * Proceso de decisión del equipo anfitrión
 
 Cuando sea posible, todo lo anterior debe ser comunicado de forma clara y detallada, desde las definiciones internas a escenario con casos especiales específicos del proyecto.
-Esta comunicación debe ser hecha de una forma que pueda ser fácilmente transmitida y comprendida por aquellos que no son parte del núcleo central del equipo.
-
+Esta comunicación debe realizarse de manera que pueda ser consultada y entendida fácilmente por aquellos que no forman parte del equipo anfitrión.
 
 === Mentorización priorizada
 

introduction/fr/03-how-works-fr.asciidoc

@@ -43,4 +43,5 @@ Plus de temps d'ingénierie est consacré à la production de code qui résout l
 
 === Ressources supplémentaires
 
+* L'équipe hôte est généralement représentée selon le modèle d'une https://patterns.innersourcecommons.org/p/core-team[Core Team]
 * Le modèle du https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer (en)].

introduction/fr/05-principles-fr.asciidoc

@@ -41,7 +41,7 @@ Cela signifie que les équipes invitées doivent être en mesure de comprendre :
 * La prise de décision de l'équipe hôte
 
 Dans la mesure du possible, les éléments ci-dessus doivent être communiqués clairement et en détail, depuis les définitions internes des équipes jusqu'aux scénarios de cas particuliers propres au projet.
-Cette communication doit être faite d'une manière qui peut être facilement interrogée et comprise par ceux qui ne font pas partie de l'équipe principale.
+Cette communication doit être effectuée de manière à ce qu'elle puisse être facilement consultée et comprise par ceux qui ne font pas partie de l'équipe hôte.
 
 === Mentorat hiérarchisé