Grammatical modifications added to the Galician translation in the te…

…xts of the corresponding .md files (#680)

* Grammatical corrections in several patterns of Galician translation (translation/gl/patterns)
* Grammatical corrections in several templates (translation/gl/templates) and book introduction (book/gl/introduction.md)

book/gl/introduction.md

@@ -3,7 +3,7 @@
 ![Modelos InnerSource](innersource-patterns-book-cover.png)
 
 {% hint style="info" %}
-Vostede está a ler unha versión preliminar do libro *Modelos InnerSource: Guía das mellores prácticas por casos: Fáciles de entender, avaliar e aplicar*, polo que é posible que algunhas ligazóns non funcionen, ou atope algún erro. Pode axudarnos a corrixilos e así poder ofrecer o mellor libro posible, se escolle facer [contribucións](contribute.md) a este libro.
+Vostede está a ler unha versión preliminar do libro *Modelos InnerSource: Guía das mellores prácticas por casos: Fáciles de entender, avaliar e aplicar*, polo que é posible que algunhas ligazóns non funcionen, ou atope algún erro. Pode axudarnos a corrixilos, e así poder ofrecer o mellor libro posible, se escolle facer [contribucións](contribute.md) a este libro.
 {% endhint %}
 
 Benvido ao libro **Modelos de InnerSource**.
@@ -14,7 +14,7 @@ Este libro contén as mellores prácticas de InnerSource debulladas nun formato
 
 Nesta introdución explicamos [que é InnerSource](#que-é-innersource), [que é un modelo](#que-son-os-modelos-innersource) e [como empregar eses modelos](#como-pode-empregar-os-modelos-innersource) na súa organización.
 
-Se xa está a empregar InnerSource na súa empresa e quere contribuír aportando experiencias a este libro, encantaríanos [recibir as súas contribucións](./contribute.md)
+Se xa está a empregar InnerSource na súa empresa e quere contribuír achegando experiencias a este libro, encantaríanos [recibir as súas contribucións](./contribute.md)
 
 ## Que é InnerSource?
 
@@ -28,34 +28,34 @@ Para as empresas que crean na súa meirande parte software de código pechado, I
 
 ## Que son os modelos InnerSource?
 
-Os modelos son unha forma de describir unha solución probada e repetible para un problema nun contexto concreto. Os modelos empregan un formato sinxelo co que, na propia aplicación da solución, axudan a comprender as limitacións do problema, os aspectos que mellorar e o contexto resultante; é dicir, a nova situación xerada trala aplicación desta solución.
+Os modelos son unha forma de describir unha solución probada e repetible para un problema nun contexto concreto. Os modelos empregan un formato sinxelo co que, na propia aplicación da solución, axudan a comprender as limitacións do problema, os aspectos que mellorar e o contexto resultante; é dicir, a nova situación xerada tras a aplicación desta solución.
 
 Os modelos poden proporcionar aos/ás participantes de InnerSource Commons un medio polo que compartir información de xeito conciso, para mellorar a práctica InnerSource. Algunhas das seccións principais destes modelos son: Título, Problema, Contexto, Aspectos que mellorar e Solucións.
 
-* [Vídeos de Youtube sobre que son os modelos](http://bit.ly/innersource_patterns_videos): Visualice esta serie de vídeos de YouTube de entre 2 e 5 minutos, na que se explican os modelos InnerSource.
-* [Webinario sobre os modelos](https://youtu.be/i-0IVhfRVFU): O 16 de marzo de 2017 levouse a cabo este webinario no que se debateu en vivo un modelo donut (minuto 24:30). É un exemplo do proceso de revisión que seguimos. Tamén pode consultar o [webinario sobre modelos InnerSource de O’Reilly do 1 de xuño de 2017](http://www.oreilly.com/pub/e/3884).
-* [Prototipo de modelo](../../translation/gl/templates/pattern-template.md): Observe a estrutura dun modelo InnerSource para ter unha idea do que acontece nun modelo novo.
+* [Vídeos de Youtube sobre que son os modelos](http://bit.ly/innersource_patterns_videos): visualice esta serie de vídeos de YouTube de entre 2 e 5 minutos, na que se explican os modelos InnerSource.
+* [Webinario sobre os modelos](https://youtu.be/i-0IVhfRVFU): o16 de marzo de 2017 levouse a cabo este webinario no que se debateu en vivo un modelo donut (minuto 24:30). É un exemplo do proceso de revisión que seguimos. Tamén pode consultar o [webinario sobre modelos InnerSource de O’Reilly do 1 de xuño de 2017](http://www.oreilly.com/pub/e/3884).
+* [Prototipo de modelo](../../translation/gl/templates/pattern-template.md): observe a estrutura dun modelo InnerSource para ter unha idea do que acontece nun modelo novo.
 * [Introdución aos modelos InnerSource (presentación en inglés do cumio de outono de 2016)](https://drive.google.com/open?id=0B7_9iQb93uBQbnlkdHNuUGhpTXc), de Tim Yao e Padma Sudarsan (PDF). Expón os antecedentes e algúns exemplos de modelos, e permitiralle comprender en detalle os motivos polos que facer uso dos nosos modelos e como facelo. Consulte tamén a [Introdución aos modelos InnerSource (do cume de outono de 2017)](https://drive.google.com/open?id=0B7_9iQb93uBQWmYwMFpyaGh4OFU) de Tim Yao e Bob Hanmer (PDF).
 
 ## Como pode empregar os modelos InnerSource?
 
 Os modelos deben empregarse coidadosamente. Non poden aplicarse de xeito indiscriminado. Na maioría dos casos, vostede necesitará adaptar unha solución á súa situación particular; mais a información proporcionada no modelo, que define o contexto (os límites inamovibles) e os aspectos que mellorar (os límites que poden cambiar e equilibrarse entre si), debería servir de axuda para poñela en práctica. Teña en conta que tamén deberá determinar se existen limitacións adicionais (o contexto e os aspectos que queira mellorar a empresa) que se apliquen á súa compañía/organización en particular e deban engadirse ao modelo (como se fose unha especie de filtro). Estas limitacións adicionais poden chegar a requirir pasos adicionais para chegar a unha solución.  
 
-O impreso do modelo é útil para describir solucións probadas, pero tamén se pode empregar para xerar ideas sobre novas solucións onde aínda non se estableceron modelos. Isto débese a que a anatomía dun modelo proporciona un marco de traballo para pensar sobre un problema dun xeito estruturado. Vostede tamén pode crear un *modelo de donut* (completando os campos de problema, contexto, aspectos que mellorar e contexto resultante; pero deixando a solución en branco) como unha forma de pedir axuda á comunidade InnerSource Commons (para encontrar unha solución comprobada ou para aportar ideas sobre que cousas probar).
+O impreso do modelo é útil para describir solucións probadas, pero tamén se pode empregar para xerar ideas sobre novas solucións onde aínda non se estableceron modelos. Isto débese a que a anatomía dun modelo proporciona un marco de traballo para pensar sobre un problema dun xeito estruturado. Vostede tamén pode crear un *modelo de donut* (completando os campos de problema, contexto, aspectos que mellorar e contexto resultante; pero deixando a solución en branco) como unha forma de pedir axuda á comunidade InnerSource Commons (para encontrar unha solución comprobada ou para achegar ideas sobre que cousas probar).
 
 ## Como contribuír?
 
-Consulte: [Como contribuír a este libro](./contribute.md).
+Consulte: [como contribuír a este libro](./contribute.md).
 
 ## Créditos
 
-Este libro é o resultado de moitos anos de traballo de incontables [contribuidores/as de software libre](https://github.com/InnerSourceCommons/InnerSourcePatterns/graphs/contributors) de todo o mundo. A súa vontade de compartir abertamente os desafíos que afrontaron as súas empresas e o xeito no que InnerSource lles axudou a abordar eses desafíos, fan deste libro un recurso valioso para calquera que inicie o seu percorrido InnerSource.
+Este libro é o resultado de moitos anos de traballo de incontables [contribuidores/as de software libre](https://github.com/InnerSourceCommons/InnerSourcePatterns/graphs/contributors) de todo o mundo. A súa vontade de compartir abertamente os desafíos que afrontaron as súas empresas e o xeito no que InnerSource os axudou a abordar eses desafíos, fan deste libro un recurso valioso para calquera que inicie o seu percorrido InnerSource.
 
 Queremos facer unha mención especial ao InnerSource Patterns Working Group, que nutriu a calidade dos modelos e axudou a outros/as a facer contribucións. E tamén compilou a selección de modelos dispoñibles neste libro.
 
 A imaxe do título do libro foi creada por [Sebastian Spier](https://spier.hu) e adaptada dunha imaxe de [Tony Hisgett - Alhambra 6](https://www.flickr.com/photos/hisgett/29345405788/), dispoñible baixo a licenza [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/).
 
-**Moitas grazas a tódolos/as contribuidores/as! E feliz día InnerSource. :)**
+**Moitas grazas a todos os/as contribuidores/as! E feliz día InnerSource. :)**
 
 ## Licenza
 

translation/gl/patterns/30-day-warranty.md

@@ -4,7 +4,7 @@ Garantía de 30 días
 
 ## Patlet
 
-Cando se aceptan contribucións externas, existe unha aversión natural do equipo a asumir a responsabilidade do código que non foi escrito por eles/as. A través da garantía de 30 días, o equipo contribuidor acepta proporcionar correccións de erros ao equipo receptor. Isto aumentará o nivel de confianza de ambos equipos e fará que sexa máis probable que se acepten as contribucións.
+cando se aceptan contribucións externas, existe unha aversión natural do equipo a asumir a responsabilidade do código que non foi escrito por eles/as. A través da garantía de 30 días, o equipo contribuidor acepta proporcionar correccións de erros ao equipo receptor. Isto aumentará o nivel de confianza de ambos os equipos e fará que sexa máis probable que se acepten as contribucións.
 
 ## Problema
 

translation/gl/patterns/base-documentation.md

@@ -4,7 +4,7 @@ Documentación base estándar
 
 ## Patlet
 
-Os/As novos/as contribuidores/as dun proxecto InnerSource teñen dificultades para determinar quen mantén o proxecto, en que traballar e como contribuír. Ao proporcionar documentación en arquivos estándar como `README.md`/`CONTRIBUTING.md` permítese un proceso de autoservizo para os/as novos/as contribuidores/as, de xeito que poidan atopar por si mesmos/as as respostas ás preguntas máis comúns.
+ós/ás novos/as contribuidores/as dun proxecto InnerSource teñen dificultades para determinar quen mantén o proxecto, en que traballar e como contribuír. Ao proporcionar documentación en arquivos estándar como README.md/CONTRIBUTING.md permítese un proceso de autoservizo para os/as novos/as contribuidores/as, de xeito que poidan atopar por si mesmos/as as respostas ás preguntas máis comúns.
 
 ## Problema
 
@@ -20,7 +20,7 @@ O proxecto debe compartirse con outros/as contribuidores/as como proxecto InnerS
 - O proxecto creouse como unha iniciativa InnerSource fai pouco. Con todo, o equipo anfitrión carece da experiencia con InnerSource. Como consecuencia, este necesita orientación para saber que información incluír na súa documentación, onde colocar esa documentación do código para que outros/as poidan atopala, ademais de entender como dirixirse ás persoas que despois van a ler esa documentación de código.
 - O proxecto converteuse nun proxecto InnerSource recentemente, o equipo anfitrión ten experiencia limitada con InnerSource. Como resultado, a documentación de código existente aborda moitos aspectos técnicos. Así a todo, non se aborda a comunicación, a coordinación ou a información necesaria para facilitar unha planificación transparente.
 - O proxecto converteuse nun proxecto InnerSource recentemente. Como resultado, a meirande parte do coñecemento implícito que existe dentro do equipo non está escrito, polo que non é visible para os/as contribuidores/as.
-- A falta de documentación de código fai que os/as posibles contribuíntes tarden moito tempo en distribuírse e comezar. Elaborar documentación de código (e mantela actualizada) require unha inversión de tempo. Incluso se o equipo anfitrión confía nos/as contribuidores/as para que lle axuden coa documentación de código que falta, esta aínda precisa dun tempo para revisarse.
+- A falta de documentación de código fai que os/as posibles contribuíntes tarden moito tempo en distribuírse e comezar. Elaborar documentación de código (e mantela actualizada) require un investimento de tempo. Incluso se o equipo anfitrión confía nos/nas contribuidores/as para que o axuden coa documentación de código que falta, esta aínda precisa dun tempo para revisarse.
 - Os membros do proxecto pasan moito tempo respondendo a preguntas con respecto á posta en marcha do devandito proxecto. Porén, manter unha base de datos exhaustiva cunha especie de preguntas de asistencia, require moito tempo e esforzo.
 - Os distintos equipos da empresa teñen estándares diverxentes respecto a como formatar o código fonte e que modelos de software empregar. Por conseguinte, a miúdo a maior parte de contribucións teñen que reescribirse ata incluso na súa totalidade. Estandarizar estes aspectos e facer que se cumpra a norma adoita requirir de moito tempo e traballo.
 - O traballo adicional resultado das explicacións repetidas e as reescrituras diminúe a utilidade do enfoque InnerSource.
@@ -36,11 +36,11 @@ Se aínda non o fixo, cree un arquivo `README.md` para o seu proxecto que conte
 
 - [A misión do proxecto](https://producingoss.com/en/producingoss.html#mission-statement) no formato máis conciso posible. Debe dar resposta ao propósito do proxecto e permitir que os/as contribuidores/as se fagan unha idea inicial de se é probable que a posta en marcha da funcionalidade suxerida estea dentro do alcance do proxecto ou non.
 - Unha sección de «Comezo» para os/as usuarios/as intermedios/as do proxecto. Esta sección debe explicar como configurar/integrar os dispositivos do proxecto, así como tamén ha de incluír unha explicación dalgúns dos primeiros pasos habituais para os/as usuarios/as recentemente incorporados/as.
-- Documentación máis detallada para os/as usuarios/as do proxecto ou unha ligazón á mesma.
-- Documentación necesaria para realizar modificacións no proxecto ou unha ligazón á mesma.
+- Documentación máis detallada para os/as usuarios/as do proxecto ou unha ligazón a ela.
+- Documentación necesaria para realizar modificacións no proxecto ou unha ligazón a ela.
 - Documentación sobre como contribuír ao proxecto ou unha ligazón á mesma.
 - Unha sección de «Comezo» que explique que canles de comunicación públicas, arquivadas e asociadas se empregan no proxecto. Isto debe incluír unha ligazón ao sistema de seguimento de incidencias do proxecto, pero tamén a calquera outro medio de discusión utilizado.
-- Unha sección de «Quen somos?» na que se explica quen son os/as [*trusted committers*](./trusted-committer.md) que están detrás do proxecto, cunha explicación na que se especifica que, na contra de contactar a estas persoas en privado, débense empregar as canles de comunicación públicas mencionadas anteriormente.
+- Unha sección de «Quen somos?» na que se explica quen son os/as [*trusted committers*](./trusted-committer.md) que están detrás do proxecto, cunha explicación na que se especifica que, na contra de contactar estas persoas en privado, se deben empregar as canles de comunicación públicas mencionadas anteriormente.
 - Unha explicación que expoña os criterios do proxecto polos que os/as contribuidores/as pasan a ser *trusted committers*, no caso de que exista esa posibilidade.
 
 ![README.md](../../../assets/img/gl/README-for-users.png)
@@ -58,14 +58,14 @@ Se a guía dos pasos para facer unha contribución é demasiado complicada, cree
 
 ![CONTRIBUTING.md](../../../assets/img/gl/CONTRIBUTING-for-contributors.png)
 
-Existen moitos e moi bos exemplos de como escribir a un `README.md`, así como do tipo de información que incluír nun arquivo `CONTRIBUTING.md` en varios proxectos de software libre. Páxinas como [*How to write a readme that rocks*](https://m.dotdev.co/how-to-write-a-readme-that-rocks-bc29f279611a) [Como escribir un README que sexa un éxito], [*Open Source Guide from GitHub*](https://opensource.guide/) [Guía de software libre en Github], así como o libro [*Producing Open Source*](https://producingoss.com/en/producingoss.html) [A creación do software libre] conteñen información valiosa sobre o tipo de información que precisa proporcionar aos/ás contribuidores/as. Posto que *Producing Open Source* non contén un capítulo sobre como escribir un bo README *per se*, o capítulo «[Getting Started](https://producingoss.com/en/producingoss.html#starting-from-what-you-have)» [Comezo] proporciona unha listaxe bastante extensa de cousas que necesitarán os membros do *host team*, os/as usuarios/as e os/as contribuidores/as. É probable que os proxectos InnerSource non cubran todos eses aspectos desde o comezo, pero a listaxe en si é útil a modo inspiración que serve para determinar aquelas áreas que se poderían incluír.
+Existen moitos e moi bos exemplos de como escribir a un `README.md`, así como do tipo de información que incluír nun arquivo `CONTRIBUTING.md` en varios proxectos de software libre. Páxinas como [*How to write a readme that rocks*](https://m.dotdev.co/how-to-write-a-readme-that-rocks-bc29f279611a) [Como escribir un README que sexa un éxito], [*Open Source Guide from GitHub*](https://opensource.guide/) [Guía de software libre en Github], así como o libro [*Producing Open Source*](https://producingoss.com/en/producingoss.html) [A creación do software libre] conteñen información valiosa sobre o tipo de información que precisa proporcionar aos/ás contribuidores/as. Posto que *Producing Open Source* non contén un capítulo sobre como escribir un bo README *per se*, o capítulo «[Getting Started](https://producingoss.com/en/producingoss.html#starting-from-what-you-have)» [Comezo] proporciona unha listaxe bastante extensa de cousas que necesitarán os membros do *host team*, os/as usuarios/as e os/as contribuidores/as. É probable que os proxectos InnerSource non cubran todos eses aspectos desde o comezo, pero a listaxe en si é útil a modo de inspiración que serve para determinar aquelas áreas que se poderían incluír.
 
 Ademais, este modelo contén dous exemplos moi básicos para que poida iniciarse de inmediato: [README-template.md](../templates/README-template.md) e [CONTRIBUTING-template.md](../templates/CONTRIBUTING-template.md)
 
 ## Contexto resultante
 
 - O tempo que tardan os/as contribuidores/as en poñerse ao día redúcese de xeito significativo.
-- Redúcese de xeito considerable o tempo dedicado a responder ás preguntas iniciais dos/as [*trusted committers*](./trusted-committer.md), o que lles permite ter máis tempo para traballar noutras tarefas.
+- Redúcese de xeito considerable o tempo dedicado a responder ás preguntas iniciais dos/das [*trusted committers*](./trusted-committer.md), o que lles permite ter máis tempo para traballar noutras tarefas.
 - As escaladas por mor de malentendidos e discordancias redúcense de xeito significativo.
 
 ## Exemplos coñecidos

translation/gl/patterns/common-requirements.md

@@ -4,7 +4,7 @@ Requisitos comúns
 
 ## Patlet
 
-O código común dun repositorio compartido non satisfai as necesidades de tódolos equipos do proxecto que desexan empregalo; isto resólvese mediante a aliñación de requisitos e a refactorización.
+o código común dun repositorio compartido non satisfai as necesidades de todos os equipos do proxecto que desexan empregalo; isto resólvese mediante a aliñación de requisitos e a refactorización.
 
 ## Problema
 

translation/gl/patterns/communication-tooling.md

@@ -4,7 +4,7 @@ Ferramentas de comunicación
 
 ## Patlet
 
-Os/As usuarios/as dun proxecto InnerSource teñen problemas para obter axuda e poñerse en contacto co *host team*. Mediante o uso sistemático de ferramentas de comunicación asíncrona, os debates serán visibles e permanecerán arquivados e accesibles; o que se traduce nunha mellora do nivel de asistencia aos/ás usuarios/as.
+os/as usuarios/as dun proxecto InnerSource teñen problemas para obter axuda e poñerse en contacto co host team. Mediante o uso sistemático de ferramentas de comunicación asíncrona, os debates serán visibles e permanecerán arquivados e accesibles; o que se traduce nunha mellora do nivel de asistencia aos/ás usuarios/as.
 
 ## Problema