Move GitHub pages source branch to main

.git-order-file

@@ -15,9 +15,9 @@
 # discussions of the -O option, and the git-config(1) man page's
 # discussion of diff.orderFile option.
 
-TSPL.docc/IntroduccionASwift/AcercaDeSwift.md
-TSPL.docc/IntroduccionASwift/Compatibilidad.md
-TSPL.docc/IntroduccionASwift/RecorridoGuiado.md
+TSPL.docc/GuidedTour/AboutSwift.md
+TSPL.docc/GuidedTour/Compatibility.md
+TSPL.docc/GuidedTour/GuidedTour.md
 
 TSPL.docc/LanguageGuide/TheBasics.md
 TSPL.docc/LanguageGuide/BasicOperators.md

.github/PULL_REQUEST_TEMPLATE.md

@@ -2,4 +2,4 @@
 Reemplaza este párrafo con tu justificación y un breve resumen de lo que se cambió.
 
 <!-- Si este pull request arregla un bug que rastreado en GitHub issues, proporciona el enlace. -->
-Fixes: <https://github.com/patternina/swift-book-es/issues/####>
+Fixes: <https://github.com/algoritmau/swift-book-es/issues/####>

CODE_OF_CONDUCT.md

@@ -2,4 +2,4 @@
 
 El código de conducta que rige sobre este proyecto se puede encontrar en <https://swift.org/code-of-conduct>.
 
-<!-- Copyright (c) 2013 - 2023 Apple Inc. y los autores del Proyecto Swift. Todos los derechos reservados. -->
+<!-- Copyright (c) 2013 - 2024 Apple Inc. y los autores del Proyecto Swift. Todos los derechos reservados. -->

CONTRIBUTING.md

@@ -1,103 +1,106 @@
-# Contributing to *The Swift Programming Language* book
-
-By submitting a pull request,
-you represent that you have the right to license your contribution
-to Apple and the community,
-and agree by submitting the patch
-that your contributions are licensed under
-the [Swift license](https://swift.org/LICENSE.txt).
-
-For small changes,
-like typo fixes and revisions within a few paragraphs,
-the discussion of those changes is usually small enough
-to be part of the pull request.
-For large changes,
-like new chapters and sections,
-start a thread in the [Swift forums][forum]
-to discuss your approach and identify possible issues
-before you invest a lot of time in writing.
-In general,
-the amount of discussion around a change before making a pull request
-corresponds to the size of that change.
-
-Content in this book follows [Apple Style Guide][asg]
-and [this book’s style guide][tspl-style].
+# Contribuyendo al libro *The Swift Programming Language*
+
+Al enviar un *pull request*,
+declaras que tienes el derecho de licenciar tu contribución
+a Apple y a la comunidad,
+y aceptas, al enviar tus cambios,
+que tus contribuciones están licenciadas bajo
+la [licencia Swift](https://swift.org/LICENSE.txt).
+
+Para cambios pequeños,
+como correcciones tipográficas y revisiones dentro de unos pocos párrafos,
+la discusión de dichos cambios suele ser lo suficientemente mínima
+para formar parte del *pull request*.
+Para cambios grandes,
+como nuevos capítulos y secciones,
+inicia un hilo en los [foros Swift][foro]
+para discutir tu enfoque e identificar posibles problemas
+antes de invertir mucho tiempo escribiendo.
+En general,
+el grado de discusión en torno a un cambio antes de hacer un *pull request*
+corresponde al tamaño de dicho cambio.
+
+El contenido de este libro sigue la [Guía de estilos de Apple][asg]
+y [la guía de estilos de este libro][tspl-style].
 
 [asg]: https://help.apple.com/applestyleguide/
-[forum]: https://forums.swift.org/c/swift-documentation/92
+[foro]: https://forums.swift.org/c/swift-documentation/92
 [tspl-style]: /Style.md
 
-## Working on a feature branch
-
-If this is your first contribution,
-start by making a fork of the Git repository.
-
-In your fork,
-make a new branch starting at `main`
-with a brief, descriptive name.
-Branch names are ephemeral:
-When a pull request is merged,
-the merge commit doesn’t include name of your feature branch.
-
-If you need to incorporate changes from `main` or resolve a merge conflict,
-merge `main` into your feature branch.
-Before creating a pull request,
-you can instead rebase your feature branch onto `main` if you prefer,
-but don't rebase commits that are part of a pull request.
-
-## Writing commit messages
-
-Use the Git commit message to communicate with other contributors --
-both the people working on the project now
-who are reviewing your changes,
-and people who join the project in the future
-who will need to understand what you changed and why.
-
-Every commit starts with a one-sentence summary.
-The summary usually fits in 50 characters,
-but it's ok to exceed that amount occasionally
-if rewriting for brevity would make it too hard to read.
-If it's hard to write a good summary,
-try breaking your changes into multiple smaller commits.
-
-If you can't explain the commit entirely in its summary,
-skip one line and add additional information.
-This additional information includes information like
-the reasons for the change,
-the approach you took when making it,
-alternatives you considered,
-and a summary of what you changed.
-Hard wrap these lines at 72 characters
-and leave a blank line between paragraphs.
-The body of a commit is plain text,
-not markdown like the content of the book.
-
-Following these formatting conventions in your commit
-makes it easier to read
-in places like the output from `git` and notification emails.
-Most text editors can help you write a commit message
-by marking lines that are too long
-and hard wrapping text automatically.
-
-## Submitting a pull request
-
-Use the following steps when creating a new pull request:
-
-1. Test that your changes build locally by running `docc preview TSPL.docc`.
-2. Create a pull request in this repository.
-3. Write a brief message in the pull request to introduce your work in context.
-
-Within a few days,
-someone will assign reviewers and start a build in CI.
-
-During the review of the pull request,
-add new commits on your branch to incorporate feedback,
-but don’t rebase or force push.
-Rewriting the branch's history
-makes it hard for reviewers to see
-what changed since the last time they reviewed your changes.
-If there are merge conflicts,
-merge `main` into your branch or use the GitHub web UI
-to resolve the conflicts when accepting the pull request.
-
-After a pull request is merged, delete the feature branch.
+## Trabajando en una rama *feature*
+
+Si esta es tu primera contribución,
+empieza por hacer un *fork* del repositorio Git.
+
+En tu *fork*,
+crea una nueva rama a partir de `main`,
+con un nombre breve y descriptivo.
+Los nombres de las ramas son efímeros:
+al incorporar (*merge*) un *pull request*,
+el *commit* de dicha incorporación no incluye el nombre de tu rama *feature*.
+
+Si necesitas integrar cambios de `main` o resolver un *merge conflict*,
+incorpora (*merge*) `main` en tu rama *feature*.
+Antes de crear un *pull request*,
+puedes *rebase* tu rama *feature* en `main`, si así lo prefieres,
+pero no uses *rebase* con *commits* que hacen parte de un *pull request*.
+
+## Escribiendo mensajes de *commits*
+
+Usa el mensaje de *commits* de Git para comunicarte con otros colaboradores:
+tanto con las personas que están trabajando en el proyecto ahora
+—quienes están revisando tus cambios—,
+como con las personas que se unan al proyecto en el futuro,
+quienes necesitarán entender qué has cambiado y por qué.
+
+Cada *commit* comienza con un resumen de una frase.
+El resumen suele caber en 50 caracteres,
+pero está bien exceder esa cantidad de vez en cuando
+si reescribirlo por brevedad lo hace demasiado difícil de leer.
+Si te resulta difícil escribir un buen resumen,
+intenta dividir los cambios en varios *commits* más pequeños.
+
+Si no puedes explicar el *commit* por completo en su resumen,
+sáltate una línea y añade información adicional.
+Esta información adicional incluye detalles como
+las razones del cambio,
+el enfoque que adoptaste al realizarlo,
+las alternativas que consideraste,
+y un resumen de lo que cambiaste.
+Aplica un *hard wrap* de 72 caracteres a estas líneas
+y deja una línea en blanco entre párrafos.
+El cuerpo de un *commit* es texto plano,
+no *markdown* como el contenido del libro.
+
+Seguir estas convenciones de formato en tu *commit*
+facilita su legibilidad
+en lugares como el *output* de `git`
+y en correos electrónicos de notificaciones.
+La mayoría de los editores de texto
+pueden ayudarte a escribir un mensaje para un *commit*
+marcando las líneas que son demasiado largas
+y aplicando *hard wrap* al texto automáticamente.
+
+## Enviando un *pull request*
+
+Sigue los siguientes pasos al crear un nuevo *pull request*:
+
+1. Comprueba que tus cambios se compilan localmente ejecutando `docc preview TSPL.docc`.
+2. Crea un *pull request* en este repositorio.
+3. Escribe un breve mensaje en el *pull request* para presentar tu trabajo en contexto.
+
+En unos días
+alguien asignará revisores e iniciará una compilación en CI.
+
+Durante la revisión del *pull request*,
+añade nuevos *commits* en tu rama para incorporar la retroalimentación,
+pero no uses *rebase* o *force push*.
+Reescribir la historia de la rama
+hace que sea difícil para los revisores ver
+qué cambió desde la última vez que revisaron tus cambios.
+Si hay *merge conflicts*,
+incorpora (*merge*) `main` en tu rama o usa la interfaz web de GitHub
+para resolver los conflictos al aceptar el *pull request*.
+
+Una vez que un *pull request* haya sido incorporado (*merged*),
+elimina la rama *feature*.