Fix translation errors and improve clarity in Spanish documentation

Author: ovas04

book/es/introduction.md

@@ -23,7 +23,7 @@ Definimos InnerSource como:
 
 > El uso de principios y prácticas de código abierto para el desarrollo de software dentro de los confines de una organización.
 
-InnerSource toma las lecciones aprendidas del desarrollo de software de código abierto y las aplica a la forma en que las empresas desarrollan software internamente. A medida que los desarrolladores se han acostumbrado a trabajar en software de código abierto de clase mundial, existe un fuerte deseo de llevar esas prácticas de vuelta dentro del firewall y aplicarlas al software que las empresas pueden ser reacias a liberar.
+InnerSource toma las lecciones aprendidas del desarrollo de software de código abierto y las aplica a la forma en que las empresas desarrollan software internamente. A medida que los desarrolladores se han acostumbrado a trabajar en software de código abierto de clase mundial, existe un fuerte deseo de llevar esas prácticas de vuelta dentro del firewall y aplicarlas al software que las empresas pueden ser reacias a publicar.
 
 Para las empresas que construyen principalmente software de código cerrado, InnerSource puede ser una gran herramienta para ayudar a romper los silos, fomentar y escalar la colaboración interna, acelerar la incorporación de nuevos ingenieros e identificar oportunidades para contribuir con software al mundo del código abierto.
 

book/es/toc.md

@@ -34,7 +34,7 @@ Instead edit toc_template.md
 * [Mercado de Gigs](../../translation/es/patterns/gig-marketplace.md) - Establece un mercado creando un sitio web interno que liste necesidades específicas de proyectos InnerSource como "Gigs" con requisitos explícitos de tiempo y habilidades. Esto permitirá a los gerentes comprender mejor el compromiso de tiempo de sus empleados y los beneficios profesionales, aumentando así la probabilidad de obtener aprobación para realizar contribuciones InnerSource.
 * [Modelo de Madurez](../../translation/es/patterns/maturity-model.md) - Los equipos han comenzado a adoptar InnerSource. La práctica se está extendiendo a múltiples departamentos. Sin embargo, la comprensión de lo que constituye un proyecto InnerSource varía. La solución es proporcionar un modelo de madurez que permita a los equipos realizar una autoevaluación y descubrir patrones y prácticas que aún no conocen.
 * [Portal InnerSource](../../translation/es/patterns/innersource-portal.md) - Los contribuidores potenciales no pueden descubrir fácilmente proyectos InnerSource que les interesen. Al crear un sitio web en la intranet que indexe toda la información disponible de proyectos InnerSource, permitirás que los contribuidores aprendan sobre proyectos que podrían interesarles y que los propietarios de proyectos InnerSource atraigan una audiencia externa.
-* [Proceso Estándar de Liberación](../../translation/es/patterns/release-process.md) - Los equipos pueden dudar en adoptar un proyecto InnerSource si no están seguros de su madurez. Para abordar esto, las notas de versión consistentes y los artefactos publicados son cruciales. Estas prácticas demuestran una fuerte dedicación al proyecto, generando confianza y asegurando a los usuarios un compromiso continuo con un software sostenible y bien gestionado.
+* [Proceso Estándar de Publicación](../../translation/es/patterns/release-process.md) - Los equipos pueden dudar en adoptar un proyecto InnerSource si no están seguros de su madurez. Para abordar esto, las notas de versión consistentes y los artefactos publicados son cruciales. Estas prácticas demuestran una fuerte dedicación al proyecto, generando confianza y asegurando a los usuarios un compromiso continuo con un software sostenible y bien gestionado.
 * [Puntuación de Actividad del Repositorio](../../translation/es/patterns/repository-activity-score.md) - Los contribuidores potenciales quieren encontrar proyectos InnerSource activos que necesiten su ayuda. Al calcular una puntuación de actividad del repositorio para cada proyecto, se puede crear una lista clasificada de proyectos (por ejemplo, en el Portal InnerSource), para que los contribuidores potenciales puedan determinar más fácilmente a qué proyecto quieren contribuir.
 * [Reconocimiento a los Participantes](../../translation/es/patterns/praise-participants.md) - Cuando recibes una contribución InnerSource, es importante agradecer al contribuidor por su tiempo y esfuerzo. Extender tu gratitud no solo reconoce efectivamente la contribución sino que también genera mayor compromiso del contribuidor y otros. Reconocer las contribuciones positivas de los contribuidores a tu proyecto InnerSource motiva a estos contribuidores (y sus gerentes) a continuar invirtiendo en el esfuerzo.
 * [Requerimientos Comunes](../../translation/es/patterns/common-requirements.md) - El código común en un repositorio compartido no satisface las necesidades de todos los equipos de proyecto que desean utilizarlo; esto se resuelve mediante la alineación de requerimientos y la refactorización.

pattern-categorization/es/innersource-program-mind-map.md

@@ -40,7 +40,7 @@
 
 #### ¿Podemos confiar en el proyecto por un período prolongado?
 
-##### [Proceso de Liberación Estándar](https://patterns.innersourcecommons.org/p/release-process)
+##### [Proceso de Publicación Estándar](https://patterns.innersourcecommons.org/p/release-process)
 
 ##### [Documentación Base Estándar](https://patterns.innersourcecommons.org/p/base-documentation)
 

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

@@ -4,7 +4,7 @@ Garantía de 30 Días
 
 ## Patlet
 
-Al aceptar contribuciones de fuera de tu propio equipo, existe una aversión natural a asumir la responsabilidad del código no escrito por el equipo mismo. A través de la Garantía de 30 Días, el equipo contribuyente se compromete a proporcionar correcciones de errores al equipo receptor, lo que aumentará el nivel de confianza entre ambos equipos y hace más probable que se acepten las contribuciones.
+Al aceptar contribuciones externas, es natural que un equipo tenga cierta aversión a asumir la responsabilidad de código escrito por otros. A través de la Garantía de 30 Días, el equipo contribuyente se compromete a proporcionar correcciones de errores al equipo receptor, lo que aumentará el nivel de confianza entre ambos equipos y hace más probable que se acepten las contribuciones.
 
 ## Problema
 
@@ -18,10 +18,10 @@ Un equipo desarrolla un componente que se utiliza en toda una organización. Est
 ## Resistencias
 
 - Existe desconfianza hacia las contribuciones debido a un historial de engaños: los equipos enviaron contribuciones a medio terminar y posteriormente presentaron solicitudes de correcciones para hacerlas listas para su uso en producción.
-- Si el código es contribuido desde fuera del equipo, el equipo tiene la sospecha natural de que el otro equipo no sabe cómo escribir código que cumpla con las expectativas del equipo receptor.
+- Si el código es contribuido desde fuera del equipo, se tiene la sospecha natural de que el otro equipo no sabe cómo escribir código que cumpla con las expectativas del equipo receptor.
 - Cada equipo busca primero ayudar a sus propios líderes a alcanzar sus objetivos. Esta dirección de lealtad puede complicar la resolución de este problema.
 - Existe una aversión natural a asumir la responsabilidad del código no escrito por uno mismo.
-- El código contribuido necesita ser reescrito considerablemente antes de ser aceptado en la base de código.
+- El código contribuido necesita ser reescrito considerablemente antes de ser aceptado en el código fuente.
 - Existe el temor de que los contribuyentes no estén disponibles para el soporte en la corrección de errores después del momento de la contribución.
 - Los equipos temen que el código contribuido lleve a costos de mantenimiento más altos pero no saben cómo controlarlo.
 - Los equipos receptores pueden temer que enseñar a otros cómo contribuir código expondrá deuda técnica en su sistema y que esa visibilidad pueda ser dañina.
@@ -32,7 +32,7 @@ Un equipo desarrolla un componente que se utiliza en toda una organización. Est
 
 Aborda los temores de ambos equipos, tanto el receptor como el contribuyente, estableciendo un **período de garantía de 30 días** que comienza cuando el código contribuido entra en producción. Durante este período de garantía, el equipo contribuyente acepta proporcionar correcciones de errores al equipo receptor.
 
-Ten en cuenta que el período de garantía podría ser de 45, 60 o 100 días también. La duración puede variar según las restricciones del proyecto, el ciclo de vida del software del proyecto, los compromisos con los clientes y otros factores.
+El período de garantía puede extenderse a 45, 60 o incluso 100 días, según las necesidades del proyecto. La duración puede variar según las restricciones del proyecto, el ciclo de vida del software del proyecto, los compromisos con los clientes y otros factores.
 
 Además, ayuda proporcionar [directrices de contribución](./base-documentation.md) claras, detallando las expectativas tanto del equipo receptor como del equipo contribuyente.
 
@@ -73,4 +73,4 @@ Además, ayuda proporcionar [directrices de contribución](./base-documentation.
 
 ## Histórico de Traducciones
 
-- **2025-04-03** - Tradución [Oscar Lobaton S.](https://github.com/ovas04)
+- **2025-04-03** - Traducción [Oscar Lobaton S.](https://github.com/ovas04)

translation/es/patterns/base-documentation.md

@@ -32,7 +32,7 @@ Abordar la necesidad de una documentación más clara para nuevos contribuidores
 
 ### README.md
 
-Si aún no existe, crea un `README.md` para tu proyecto. Debe contener:
+Si tu proyecto aún no tiene un README.md, créalo e incluye lo siguiente:
 
 * La [misión del proyecto](https://producingoss.com/en/producingoss.html#mission-statement) en un formato lo más conciso posible. Debe responder cuál es el propósito del proyecto y permitir a los contribuidores hacer una buena suposición inicial sobre si una funcionalidad sugerida probablemente estará dentro del alcance del proyecto o no.
 * Una sección de "Primeros pasos" para los usuarios del proyecto. Debe explicar cómo configurar/integrar los artefactos del proyecto, así como una explicación de algunos de los primeros pasos típicos para los usuarios primerizos.
@@ -129,4 +129,4 @@ Ilustraciones de [Web](https://storyset.com/web) y [People](https://storyset.com
 
 ## Histórico de Traducciones
 
-- **2025-04-03** - Tradución [Oscar Lobaton S.](https://github.com/ovas04)
+- **2025-04-03** - Traducción [Oscar Lobaton S.](https://github.com/ovas04)

translation/es/patterns/common-requirements.md

@@ -36,7 +36,7 @@ Hay dos aspectos para resolver este problema que deben realizarse en paralelo:
 1. Alinear los requerimientos de los proyectos para que el código que cumple los requerimientos de un proyecto también satisfaga las necesidades de los otros proyectos.
 2. Refactorizar el código en piezas más pequeñas para las cuales los múltiples proyectos que lo utilizan puedan acordar requerimientos.
 
-Adicionalmente, aprovechar que los clientes esperan que el proveedor ayude a elucidar los requerimientos. Lograr la alineación de requerimientos durante las negociaciones con el cliente e influir en los requerimientos del cliente en lugar de cambiar el componente.
+Adicionalmente, aprovechar que los clientes esperan que el proveedor ayude a comprender los requerimientos. Lograr la alineación de requerimientos durante las negociaciones con el cliente e influir en los requerimientos del cliente en lugar de cambiar el componente.
 
 En el ejemplo presentado anteriormente, el proveedor ayuda a ambos clientes a darse cuenta de que quieren lo mismo, y ahorrará esfuerzo (y dinero) a todos si acuerdan aceptar el resultado en el mismo formato.
 
@@ -73,4 +73,4 @@ Robert Hanmer
 
 ## Histórico de Traducciones
 
-- **2025-04-03** - Tradución [Oscar Lobaton S.](https://github.com/ovas04)
+- **2025-04-03** - Traducción [Oscar Lobaton S.](https://github.com/ovas04)

translation/es/patterns/communication-tooling.md

@@ -52,7 +52,7 @@ Con las preguntas siendo respondidas en público, más personas pueden agregar s
 
 Mantener la comunicación en canales asincrónicos permite que los participantes con diferentes horarios - ya sea debido a diferentes zonas horarias o debido a diferentes rutinas, horarios de reuniones, rutinas de equipo - contribuyan significativamente al proyecto.
 
-Responder preguntas en estos canales significa que no solo otros miembros del equipo pueden escuchar y proporcionar información adicional, sino que también significa que otros usuarios con la misma pregunta ven (o encuentran más tarde) la respuesta anterior, lo que lleva a una menor necesidad de repetir explicaciones.
+Responder preguntas en estos canales significa que no solo otros miembros del equipo pueden escuchar y proporcionar información adicional, sino que también que otros usuarios con la misma pregunta ven (o encuentran más tarde) la respuesta anterior, lo que lleva a una menor necesidad de repetir explicaciones.
 
 ## Instancias Conocidas
 
@@ -79,4 +79,4 @@ Ilustraciones de [People](https://storyset.com/people) por Storyset
 
 ## Histórico de Traducciones
 
-- **2025-04-03** - Tradución [Oscar Lobaton S.](https://github.com/ovas04)
+- **2025-04-03** - Traducción [Oscar Lobaton S.](https://github.com/ovas04)

translation/es/patterns/contracted-contributor.md

@@ -8,13 +8,15 @@ Los colaboradores que desean contribuir a InnerSource son desalentados por su ge
 
 ## Problema
 
-Sin el apoyo de la gerencia media, el número total de colaboradores y, como resultado, la cantidad de contribuciones realizadas y el valor generado por la iniciativa InnerSource probablemente estará por debajo de las expectativas de la alta dirección. Esto probablemente se amplificará si no hay financiamiento adecuado y empoderamiento de los [Dedicated Community Leaders](dedicated-community-leader.md). Esto corre el riesgo de que la alta dirección abandone la idea de InnerSource.
+Sin el apoyo de la gerencia media, la cantidad de colaboradores y, en consecuencia, el número de contribuciones y el valor generado por la iniciativa InnerSource probablemente estarán por debajo de las expectativas de la alta dirección. Esto probablemente podría agravarse si no hay financiamiento adecuado y empoderamiento de los [Dedicated Community Leaders](dedicated-community-leader.md). Esto corre el riesgo de que la alta dirección abandone la idea de InnerSource.
 
 ## Contexto
 
 Una gran corporación ha iniciado una iniciativa InnerSource. Los objetivos principales de la iniciativa son aumentar la eficiencia del desarrollo de software distribuido y fomentar la innovación permitiendo que cada colaborador contribuya voluntariamente a proyectos InnerSource, independientemente del tema y la unidad de negocio.
 
-La alta dirección está a bordo y apoyando la iniciativa InnerSource. Para ellos, la iniciativa InnerSource es solo una de las muchas iniciativas para fomentar la innovación y la eficiencia. Están financiando InnerSource con dinero y capacidad para líderes comunitarios y están dando gran autonomía en cuanto a cómo se gasta el presupuesto. También están limitando el alcance y la duración de la iniciativa y participan en revisiones periódicas hasta que haya pruebas de que produce los resultados esperados (ver [Review Committee](review-committee.md)). La alta dirección ha anunciado su apoyo a InnerSource en varias reuniones internas de la empresa.
+La alta dirección está a bordo y apoyando la iniciativa InnerSource. Para ellos, la iniciativa InnerSource es solo una de las muchas iniciativas para fomentar la innovación y la eficiencia.
+Están financiando InnerSource con dinero y capacidad para líderes comunitarios y están dando gran autonomía en cuanto a cómo se gasta el presupuesto. También están limitando el alcance y la duración de la iniciativa y participan en revisiones periódicas hasta que haya pruebas de que produce los resultados esperados (ver [Review Committee](review-committee.md)).
+La alta dirección ha anunciado su apoyo a InnerSource en varias reuniones internas de la empresa.
 
 Sin embargo, la alta dirección aún no ha empoderado ni incentivado a los gerentes de nivel medio para permitir o incluso motivar a sus empleados a participar en actividades de InnerSource interdivisionales. Además de eso, la capacidad de cada colaborador generalmente se asigna a proyectos que no son de InnerSource para el 100 % de su tiempo de trabajo. La colaboración interorganizacional aún no es la norma y los gerentes de línea generalmente no tienen objetivos fuera de su propia organización. Se espera que las contribuciones a los proyectos de InnerSource se realicen durante el horario laboral, no durante el tiempo libre.
 
@@ -88,4 +90,4 @@ Un contrato formal también es beneficioso para los colaboradores y las comunida
 
 ## Histórico de Traducciones
 
-- **2025-04-03** - Tradución [Oscar Lobaton S.](https://github.com/ovas04)
+- **2025-04-03** - Traducción [Oscar Lobaton S.](https://github.com/ovas04)

translation/es/patterns/core-team.md

@@ -4,7 +4,7 @@ Equipo Central (Core Team)
 
 ## Patlet
 
-Incluso cuando un proyecto InnerSource es ampliamente necesario, las contribuciones y el uso pueden verse obstaculizados porque el proyecto es difícil de trabajar.
+Incluso cuando un proyecto InnerSource es ampliamente necesario, las contribuciones y el uso pueden verse obstaculizados porque el proyecto es difícil de manejar.
 Establece un equipo central dedicado a ocuparse de los elementos fundamentales del proyecto. Su trabajo permite que los contribuyentes agreguen y utilicen las funciones que aportan valor a sus escenarios.
 
 ## Problema
@@ -27,7 +27,7 @@ Hay un proyecto central del que todos dependen.
 ¡Qué gran candidato para InnerSource!
 Desafortunadamente, el proyecto ha crecido orgánicamente, con varias contribuciones y adiciones hechas de manera desordenada.
 Ahora es un lío espeso de código que nadie entiende y todos temen tocar.
-Claramente necesita una revisión (por ejemplo, refactorización, pruebas, documentación, etc.), pero aunque todos necesitan y quieren que ese trabajo se realice, nadie se toma el tiempo para hacerlo.
+Claramente necesita una revisión (por ejemplo, refactorización, pruebas, documentación, etc.), pero, aunque todos lo consideran necesario, nadie se toma el tiempo para hacerlo.
 
 ## Contexto
 
@@ -44,9 +44,9 @@ Claramente necesita una revisión (por ejemplo, refactorización, pruebas, docum
 ## Solución
 
 Forma un equipo central cuyo trabajo sea mantener este proyecto en un estado que permita a otros integrarse y contribuir fácilmente.
-Este equipo central realiza el trabajo necesario para un ecosistema de uso y contribución saludable.
+Este equipo se encarga de garantizar un ecosistema saludable para el uso y la contribución.
 Este trabajo crítico tiende a no ser priorizado como una contribución.
-Las categorías de este tipo de trabajo incluyen comunicación, entorno local e infraestructura de DevOps.
+Las principales áreas de enfoque incluyen comunicación, entorno local e infraestructura de DevOps.
 
 Aquí hay algunos ejemplos específicos:
 
@@ -94,7 +94,7 @@ El equipo central llena esos vacíos y engrasa las ruedas para que el ecosistema
 
 ## Instancias Conocidas
 
-* **Nike** implementó este patrón para gestionar el esfuerzo InnerSource en torno a sus pipelines reutilizables de CI/CD.
+* **Nike** implementó este patrón para gestionar su iniciativa InnerSource en torno a sus pipelines reutilizables de CI/CD.
 * **WellSky** estableció un Equipo Central para un proyecto clave. Esto les permitió escalar significativamente sus contribuciones InnerSource a ese proyecto - ver [Wide-Scaled InnerSource with a Core Team](https://www.youtube.com/watch?v=kgxexjYdhIc).
 * **BBVA AI Factory** implementó este patrón como parte de una estrategia InnerSource para fomentar la contribución y reutilización del código de ciencia de datos - ver [Mercury: Scaling Data Science reusability at BBVA](https://www.bbvaaifactory.com/mercury-acelerando-la-reutilizacion-en-ciencia-de-datos-dentro-de-bbva/).
 
@@ -111,4 +111,4 @@ Estructurado
 
 ## Histórico de Traducciones
 
-- **2025-04-03** - Tradución [Oscar Lobaton S.](https://github.com/ovas04)
+- **2025-04-03** - Traducción [Oscar Lobaton S.](https://github.com/ovas04)