git: 2ee2fc3cf4 - main - [doc-es][articles/problem-reports]: finish translation

The branch main has been updated by fernape:

URL: https://cgit.FreeBSD.org/doc/commit/?id=2ee2fc3cf40f008c08f03c2fe9e7523133c42599

commit 2ee2fc3cf40f008c08f03c2fe9e7523133c42599
Author:     Fernando Apesteguía <fernape@FreeBSD.org>
AuthorDate: 2022-10-12 17:51:02 +0000
Commit:     Fernando Apesteguía <fernape@FreeBSD.org>
CommitDate: 2022-10-13 15:17:45 +0000

    [doc-es][articles/problem-reports]: finish translation
---
 .../es/articles/problem-reports/_index.adoc        |  198 +--
 .../content/es/articles/problem-reports/_index.po  | 1445 ++++++++++++++++++++
 2 files changed, 1546 insertions(+), 97 deletions(-)

diff --git a/documentation/content/es/articles/problem-reports/_index.adoc b/documentation/content/es/articles/problem-reports/_index.adoc
index 678bdfc25a..fca0b73f38 100644
--- a/documentation/content/es/articles/problem-reports/_index.adoc
+++ b/documentation/content/es/articles/problem-reports/_index.adoc
@@ -1,12 +1,16 @@
 ---
-title: Escribiendo informes de problemas de FreeBSD
 authors:
-  - author: Dag-Erling Smørgrav
-  - author: Mark Linimon
+  - 
+    author: 'Dag-Erling Smørgrav'
+  - 
+    author: 'Mark Linimon'
+description: 'Cómo realizar y enviar informes de problemas para el proyecto FreeBSD de la mejor forma posible'
+tags: ["formulate", "submit", "FreeBSD", "PR"]
+title: 'Escribiendo Informes de Problemas de FreeBSD'
 trademarks: ["freebsd", "ibm", "intel", "sun", "general"]
 ---
 
-= Escribiendo informes de problemas de FreeBSD
+= Escribiendo Informes de Problemas de FreeBSD
 :doctype: article
 :toc: macro
 :toclevels: 1
@@ -40,7 +44,7 @@ endif::[]
 [.abstract-title]
 Resumen
 
-Este artículo describe cómo realizar y enviar informes de problemas para el proyecto FreeBSD de la mejor forma posible.
+Este artículo describe cómo realizar y enviar informes de problemas para el Proyecto FreeBSD de la mejor forma posible.
 
 '''
 
@@ -49,199 +53,199 @@ toc::[]
 [[pr-intro]]
 == Introducción
 
-Una de las experiencias más frustrantes que uno puede tener como usuario de software es enviar un informe de problemas solo para que se cierre sumariamente con una explicación breve e inútil como "no es un error" o "PR erróneo". De manera similar, una de las experiencias más frustrantes que puede experimentar un desarrollador de aplicaciones consiste en verse inundado por una cantidad ingente de informes de problemas que en realidad vienen a ser solicitudes de soporte o ayuda, o que contienen poca o ninguna información sobre cúal es el problema y cómo reproducirlo.
+Una de las experiencias más frustrantes que uno puede tener como usuario de software es enviar un informe de problemas solo para que se cierre sumariamente con una explicación breve e inútil como "no es un error" o "PR erróneo". De manera similar, una de las experiencias más frustrantes que puede experimentar un desarrollador de aplicaciones consiste en verse inundado por una cantidad ingente de informes de problemas que en realidad vienen a ser solicitudes de soporte o ayuda, o que contienen poca o ninguna información sobre cual es el problema y cómo reproducirlo.
 
-Este documento intenta describir cómo escribir buenos informes de problemas. ¿Qué, se preguntará, es un buen informe de problemas? Bien, para ir directos al grano, un buen informe de problemas es aquél que se puede analizar y tratar rápidamente, para mutua satisfacción del usuario y del desarrollador.
+Este documento intenta describir cómo escribir buenos informes de problemas. ¿Qué, te preguntarás, es un buen informe de problemas? Bien, para ir directos al grano, un buen informe de problemas es aquél que se puede analizar y tratar rápidamente, para mutua satisfacción del usuario y del desarrollador.
 
 Aunque el objetivo principal de este artículo se centra en los informes de problemas de FreeBSD, la mayoría de los conceptos se pueden aplicar bastante bien en otros proyectos de software.
 
-Tenga en cuenta que este artículo está organizado temáticamente, no cronológicamente. Lea todo el documento antes de enviar un informe de problemas, en lugar de tratarlo como un tutorial paso a paso.
+Ten en cuenta que este artículo está organizado temáticamente, no cronológicamente. Lee todo el documento antes de enviar un informe de problemas, en lugar de tratarlo como un tutorial paso a paso.
 
 [[pr-when]]
-== Cuándo enviar informes de problemas
+== Cuándo Enviar Informes de Problemas
 
-Hay muchos tipos de problemas y no todos ellos merecen la creación de un informe de problemas. Por supuesto, nadie es perfecto, y habrá ocasiones en que lo que parece ser un error en un programa es, de hecho, un malentendido de la sintaxis de un comando o un error tipográfico en un archivo de configuración (aunque en este último caso podría tratarse de un indicador de documentación escasa o que la aplicación peca de una gestión de errores defectuosa). Incluso teniendo estos aspectos en cuenta existen varios casos en los cuales el envío de un informe de problemas resulta claramente _no ser_ la mejor forma de proceder, y solo servirá para frustrar tanto al remitente como a los desarrolladores. Por el contrario, hay casos en los que podría ser apropiado enviar un informe de problemas sobre algo más que un error: una mejora o una nueva característica, por ejemplo.
+Hay muchos tipos de problemas y no todos ellos merecen la creación de un informe de problemas. Por supuesto, nadie es perfecto, y habrá ocasiones en que lo que parece ser un error en un programa es, de hecho, un malentendido de la sintaxis de un comando o un error tipográfico en un archivo de configuración (aunque en este último caso podría tratarse de un indicador de documentación escasa o que la aplicación peca de una gestión de errores defectuosa). Incluso teniendo estos aspectos en cuenta existen varios casos en los cuales el envío de un informe de problemas resulta claramente _no ser_ la mejor forma de proceder y solo servirá para frustrar tanto al remitente como a los desarrolladores. Por el contrario, hay casos en los que podría ser apropiado enviar un informe de problemas sobre algo más que un error: una mejora o una nueva característica, por ejemplo.
 
-Entonces, ¿cómo se determina qué es un error y qué no? Como regla general, el problema _no_ es un error si puede expresarse como una pregunta (normalmente del estilo de "¿Cómo hago X?" o "¿Dónde puedo encontrar Y?"). Las cosas no son siempre blancas o negras, pero la regla de la pregunta cubre la gran mayoría de los casos. Al buscar una respuesta, considere plantear la pregunta a la http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions[lista de correo de preguntas generales de FreeBSD].
+Entonces ¿cómo determinar lo que es un bug y lo que no? Una regla sencilla es que el problema _no_ es un bug si se puede expresar como una pregunta (normalmente de la forma "¿Cómo hago X?" o "¿Dónde puedo encontrar Y?"). No siempre todo es blanco o negro, pero la regla de la pregunta cubre una gran mayoría de los casos. Cuando estés buscando una respuesta, considera hacer la pregunta en la {freebsd-questions}.
 
-Tenga en cuenta estos factores al enviar PRs sobre ports u otro software que no sea parte de FreeBSD:
+Ten en cuenta estos factores al enviar PRs sobre ports u otro software que no sea parte de FreeBSD:
 
-* Por favor, no envíe informes de problemas que simplemente indiquen la disponibilidad de una nueva versión de una aplicación. Los maintainers de ports son notificados automáticamente por portscout cuando una nueva versión de una aplicación esta disponible. Los parches para actualizar un port a la última versión son bien recibidos.
-* Para los ports que no están mantenidos (el `MAINTAINER` es `ports@FreeBSD.org`), es poco probable que un PR sin un parche adjunto sea cogido por un committer. Para convertirse en el maintainer de un port que no este mantenido, envíe un PR con la petición (sería ideal si viene con un parche adjunto, pero no es necesario).
-* En cualquier caso, seguir el proceso descrito en el extref:{porters-handbook}[Manual del Porter, port-upgrading] dará los mejores resultados. (Es posible que también desee leer extref:{contributing}[Cómo contribuir a la colección de ports de FreeBSD, ports-contributing]).
+* Por favor, no envíes informes de problemas que simplemente indiquen la disponibilidad de una nueva versión de una aplicación. Los maintainers de ports son notificados automáticamente por portscout cuando una nueva versión de una aplicación esta disponible. Los parches para actualizar un port a la última versión son bien recibidos.
+* Para ports sin mantener (`MAINTAINER` es `ports@FreeBSD.org`), un PR sin un parche incluido tiene pocas posibilidades de ser cogido por un committer. Para convertirte en el maintainer de un port sin mantenedor, envía un PR con la petición (y con el parche preferentemente aunque no es obligatorio).
+* En cualquier caso, seguir el proceso descrito en el extref:{porters-handbook}upgrading/[Porter's Handbook] ofrecerá los mejores resultados. (También podrías querer leer extref:{contributing}[Contribuyendo a la Colección de Ports de FreeBSD, ports-contributing].)
 
-Un error que no se puede reproducir rara vez se podrá arreglar. Si el error solo ocurrió una vez y no puede reproducirlo, y no parece que le ocurra a nadie más, es probable que ninguno de los desarrolladores pueda reproducirlo o descubrir qué es lo que está mal. Eso no significa que no haya ocurrido, significa que las posibilidades de que su informe de problemas lleve a la corrección del error son muy escasas. Para empeorar las cosas, a menudo, este tipo de errores son en realidad causados por fallos en los discos duros o procesadores con sobrecalentamiento, siempre debe intentar descartar estas causas, siempre que sea posible, antes de enviar un PR.
+Un error que no se puede reproducir rara vez se podrá arreglar. Si el error solo ocurrió una vez y no puedes reproducirlo, y no parece que le ocurra a nadie más, es probable que ninguno de los desarrolladores pueda reproducirlo o descubrir qué es lo que está mal. Eso no significa que no haya ocurrido, significa que las posibilidades de que tu informe de problemas lleve a la corrección del error son muy escasas. Para empeorar las cosas, a menudo, este tipo de errores son en realidad causados por fallos en los discos duros o procesadores con sobrecalentamiento, siempre debes intentar descartar estas causas, siempre que sea posible, antes de enviar un PR.
 
-A continuación, para decidir a quién debe presentar su informe de problemas, debe comprender que el software que compone FreeBSD está compuesto de varios elementos diferentes:
+A continuación, para decidir a quién debe presentar su informe de problemas, debes comprender que el software que compone FreeBSD está compuesto de varios elementos diferentes:
 
 * El código en el sistema base que escriben y mantienen los colaboradores de FreeBSD, como el kernel, la biblioteca de C y los controladores de dispositivos (categorizados como `kern`); las utilidades binarias (`bin`); las páginas del manual y documentación (`docs`); y las páginas web (`www`). Todos los errores en estas áreas deben informarse a los desarrolladores de FreeBSD.
-* El código en el sistema base escrito y mantenido por otros, e importado y adaptado a FreeBSD. Los ejemplos incluyen man:clang[1] y man:sendmail[8]. La mayoría de los errores en estas áreas deben informarse a los desarrolladores de FreeBSD; pero en algunos casos es posible que deban informarse a los autores originales si los problemas no son específicos de FreeBSD.
-* Las aplicaciones individuales que no están en el sistema base, sino que forman parte de la colección de ports de FreeBSD (categoría `ports`). La mayoría de estas aplicaciones no están escritas por los desarrolladores de FreeBSD; lo que proporciona FreeBSD es simplemente un framework para instalar la aplicación. Por lo tanto, solo informe de un problema a los desarrolladores de FreeBSD cuando crea que el problema es específico de FreeBSD; de lo contrario, repórtelo a los autores del software.
+* Código en el sistema base que es escrito y mantenido por otros, e importado y adaptado a FreeBSD. Ejemplos de esto son man:clang[1], y man:sendmail[8]. La mayoría de los errores en estas áreas deberían ser reportados a los desarrolladores de FreeBSD; pero en algunos casos deberían ser reportados a los autores originales si los problemas no son específicos de FreeBSD.
+* Las aplicaciones individuales que no están en el sistema base, sino que forman parte de la colección de ports de FreeBSD (categoría `ports`). La mayoría de estas aplicaciones no están escritas por los desarrolladores de FreeBSD; lo que proporciona FreeBSD es simplemente un framework para instalar la aplicación. Por lo tanto, informa de un problema a los desarrolladores de FreeBSD sólo cuando creas que el problema es específico de FreeBSD; de lo contrario, repórtalo a los autores del software.
 
-Después, averigüe si es un problema puntual. Existen pocas cosas que molesten más a un desarrollador que recibir un informe de problemas sobre un error que ya ha solucionado.
+Después, averigua si es un problema puntual. Existen pocas cosas que molesten más a un desarrollador que recibir un informe de problemas sobre un error que ya ha solucionado.
 
-Si el problema está en el sistema base, primero lea la sección de preguntas frecuentes sobre las extref:{faq}[versiones de FreeBSD, LATEST-VERSION], si aún no está familiarizado con el tema. FreeBSD no puede solucionar problemas en otras ramas que no sean las más recientes del sistema base, por lo que presentar un informe de error sobre una versión anterior probablemente hará que un desarrollador le aconseje que se actualice a una versión soportada para comprobar si el problema todavía sucede. El equipo Security Officer mantiene https://www.FreeBSD.org/security/[la lista de versiones soportadas].
+Si el problema es en el sistema base, primero lee la sección FAQ de extref:{faq}[FreeBSD versions, latest-version], si no estás familiarizado con el tema. Para FreeBSD no es posible arreglar problemas en otra cosa que no sean las ramas más recientes del sistema base, de forma que reportar un error acerca de una versión más antigua probablemente resulte en un desarrollador que te aconseja actualizarte a una versión soportada para ver si el problema sigue ocurriendo. El equipo del Security Officer mantiene la link:https://www.FreeBSD.org/security/[lista de versiones soportadas].
 
-Si el problema está en un port, considere enviar el error al upstream. El proyecto FreeBSD no puede corregir todos los errores en todo el software.
+Si el problema está en un port, considera enviar el error al proyecto original (upstream). El Proyecto FreeBSD no puede corregir todos los errores en todo el software.
 
 [[pr-prep]]
 == Preparativos
 
-Una buena regla que se puede seguir consiste en realizar siempre una búsqueda antes de enviar un informe de problemas. Quizá nuestro problema ya ha sido reportado; quizá se está discutiendo en las listas de correo o fue discutido hace poco; incluso puede que ya esté arreglado en una versión más nueva que la que está ejecutando. Por lo tanto, se deben consultar los sitios y fuentes más obvias antes de proceder con el envío del informe de errores. En FreeBSD, esto significa:
+Una buena regla que se puede seguir consiste en realizar siempre una búsqueda antes de enviar un informe de problemas. Quizá nuestro problema ya ha sido reportado; quizá se está discutiendo en las listas de correo o fue discutido hace poco; incluso puede que ya esté arreglado en una versión más nueva que la que estás ejecutando. Por lo tanto, se deben consultar los sitios y fuentes más obvias antes de proceder con el envío del informe de errores. En FreeBSD, esto significa:
 
-* La lista de extref:{faq}[preguntas más frecuentes] (FAQ) de FreeBSD. Las preguntas frecuentes intentan proporcionar respuestas a una amplia gama de preguntas, como las relacionadas con la extref:{faq}[compatibilidad del hardware, hardware], las extref:{faq}[aplicaciones de usuario, applications] y la extref:{faq}[configuración del kernel, kernelconfig].
-* Las extref:{handbook}eresources[listas de correo, eresources-mail], si no está suscrito, utilice la https://www.FreeBSD.org/search/#mailinglists[búsqueda en los archivos] del sitio web de FreeBSD. Si el problema no se ha discutido con anterioridad en las listas, se puede intentar enviar un mensaje y esperar unos pocos días para ver si alguien puede aconsejarle adecuadamente sobre algún punto que quizá haya pasado por alto en relación con el problema.
-* Opcionalmente, toda la web: utilice su motor de búsqueda favorito para localizar cualquier referencia al problema. Incluso puede obtener listas de correo archivadas o grupos de noticias que no conocía o en los que no había pensado buscar.
-* A continuación, la búsqueda a través de la https://bugs.freebsd.org/bugzilla/query.cgi[base de datos de PR de FreeBSD] (Bugzilla). A menos que el problema sea muy reciente o rebuscado, existe un gran número de posibilidades de que ya haya sido informado o reportado.
+* La lista extref:{faq}[Frequently Asked Questions] (FAQ) de FreeBSD. La FAQ intenta proporcionar respuestas para un gran rango de preguntas como las que tienen que ver con extref:{faq}[compatibilidad de hardware, hardware], extref:{faq}[aplicaciones de usuario, applications], y extref:{faq}[configuración del kernel, kernelconfig].
+* Las extref:{handbook}eresources/[listas de correo, eresources-mail]- si todavía no estás suscrito, usa https://www.FreeBSD.org/search/#mailinglists[la búsqueda del histórico] en el sitio web de FreeBSD. Si el problema no ha sido discutido en las listas, podrías probar a mandar un mensaje sobre ello y esperar unos días a ver si alguien se fija en algo que haya sido pasado por alto.
+* Opcionalmente, toda la web: utiliza tu motor de búsqueda favorito para localizar cualquier referencia al problema. Incluso puedes obtener listas de correo archivadas o grupos de noticias que no conocías o en los que no habías pensado buscar.
+* Después, la https://bugs.freebsd.org/bugzilla/query.cgi[base de datos de PR de FreeBSD] (Bugzilla) en la que se puede buscar. A menos que el problema sea reciente u oscuro, hay buenas posibilidades de que ya haya sido reportado.
 * Lo más importante, se debería intentar comprobar si la documentación existente en el código fuente del programa puede resolver el problema.
-+ 
-Para el código base de FreeBSD, debe estudiar cuidadosamente el contenido del fichero [.filename]#/usr/src/UPDATING# del sistema o la versión más reciente en https://svnweb.freebsd.org/base/head/UPDATING?view=log[https://svnweb.freebsd.org/base/head/UPDATING?view=log]. (Esta información se considera de vital importancia si se está actualizando de una versión a otra, especialmente si está actualizando a la rama de FreeBSD-CURRENT).
-+ 
-No obstante, si el problema se encuentra en algo que se instaló como parte de la colección de ports de FreeBSD, se debe consultar el archivo [.filename]#/usr/ports/UPDATING# (para ports individuales) o el archivo [.filename]#/usr/ports/CHANGES# (para cambios que afectan a la colección de ports completa). https://svnweb.freebsd.org/ports/head/UPDATING?view=log[https://svnweb.freebsd.org/port/head/UPDATING?view=log] y https://svnweb.freebsd.org/ports/head/CHANGES?view=log[https://svnweb.freebsd.org/ports/head/CHANGES?view=log] también están disponibles a través de svnweb.
++
+Para el código base de FreeBSD, deberías estudiar detenidamente el contenido de [.filename]#/usr/src/UPDATING# de tu sistema o la última versión en https://cgit.freebsd.org/src/tree/UPDATING[https://cgit.freebsd.org/src/tree/UPDATING]. (Es información vital si estás actualizando de una versión a otra - especialmente si estás actualizando la rama FreeBSD-CURRENT).
++
+Sin embargo, si el problema está en algo que ha sido instalado como parte de la Colección de Ports de FreeBSD, deberías mirar en [.filename]#/usr/ports/UPDATING# (para ports individuales) o [.filename]#/usr/ports/CHANGES# (para cambios que afectan a toda la Colección de Ports). https://cgit.freebsd.org/ports/tree/UPDATING[https://cgit.freebsd.org/ports/tree/UPDATING] y https://cgit.freebsd.org/ports/tree/CHANGES[https://cgit.freebsd.org/ports/tree/CHANGES] también están disponibles vía cgit.
 
 [[pr-writing]]
 == Escribiendo el informe de problemas
 
-Ahora que ha decidido que su problema merece un informe de problemas y que es un problema de FreeBSD, es el momento de escribir el informe de problemas propiamente dicho. Antes de pasar a describir los mecanismos utilizados por el programa encargado de generar y enviar los PRs, aquí hay algunos consejos y trucos para ayudarle a asegurarse de que su PR sea más efectivo.
+Ahora que has decidido que tu problema merece un informe de problemas y que es un problema de FreeBSD, es el momento de escribir el informe de problemas propiamente dicho. Antes de pasar a describir los mecanismos utilizados por el programa encargado de generar y enviar los PRs, aquí hay algunos consejos y trucos que te ayudarán a garantizar de que tu PR sea más efectivo.
 
 [[pr-writing-tips]]
 == Consejos y trucos para escribir un buen informe de problemas
 
-* _No deje el campo "Summary" vacío._ Los PRs se envían a una lista de correo global (donde se utiliza el campo "Summary" para la línea `Subject:`), y se almacenan en una base de datos. Cualquiera que haga una búsqueda por el campo synopsis (sinopsis) en la base de datos y encuentre un PR con la línea del subject (asunto) en blanco tiende a omitirlo. Recuerde que los PR permanecen en esta base de datos hasta que alguien los cierra; un PR que no esté debidamente cumplimentado pasará desapercibido.
-* _Rellene el campo "Summary" correctamente, no use descripciones vagas._ No asuma que aquella persona que lea su PR entienda el contexto que motivó su envío, por lo tanto, cuanta más información proporcione, mejor. Por ejemplo, ¿en qué parte del sistema se produce el problema? ¿El problema sucede solo durante la instalación o durante la ejecución del sistema? Por ejemplo, en lugar de, `Summary: portupgrade is broken`, podría utilizar este otro, el cual, tiene mucha más información: `Summary: port ports-mgmt/portupgrade coredumps on -current`. (En el caso de los ports, es especialmente útil tener el nombre de la categoría y el nombre del port en el campo "Summary").
-* _Si tiene un parche, dígalo._ Es más probable que se analice un PR con un parche incluido que uno sin él. Incluya la palabra clave `patch` en Bugzilla.
-* __Si es un maintainer, dígalo__. Si mantiene una parte del código fuente (por ejemplo, un port que ya exista), debe establecer el campo "Class" de su PR a `maintainer-update`. De esta forma, cualquier committer que se ocupe de su PR no tendrá que verificarlo.
-* _Sea concreto._ Cuanta más información se proporcione sobre el problema que tiene, más posibilidades de obtener una respuesta.
+* _No dejes la línea "Summary" vacía._ Los PRs van tanto a una lista de correo que va a todo el mundo (donde "Summary" se utiliza para la línea `Subject:`), pero también a una base de datos. Cualquiera que tiempo después aparece y busca en la base de datos por sinopsis y encuentra un PR con la línea de tema en blanco, tiende a saltársela. Recuerda que los PR se mantienen en esta base de datos hasta que alguien los cierra; una anónima desaparecerá entre el ruido.
+* _Evita el uso de líneas "Summary" débiles._ No deberías asumir que alguien que lee tu PR tiene contexto acerca del mismo, así que cuando más proporciones, mejor. Por ejemplo, ¿a qué parte del sistema se refiere el problema?¿Sólo ves el problema al instalar o mientras ejecutas? Para ilustrar este punto, en lugar de `Summary: portupgrade está roto`, fíjate cómo esto es más informativo: `Summary: el port ports-mgmt/portupgrade genera un core en -current`. (En el caso de los ports, es especialmente útil tener tanto la categoría como el port en la línea "Summary".)
+* _Si tienes un parche, dilo._ Un PR que incluye un parche tiene más posibilidades de recibir atención que uno que no lo tiene. Por favor, establece la Keyword `patch` en Bugzilla.
+* _Si eres un mantenedor, dilo._ Si mantienes una parte del código fuente (por ejemplo, un port), entonces deberías establecer el "Class" de tu PR a `maintainer-update`. De este modo cualquier committer que se asigne tu PR no tendrá que comprobarlo.
+* _Sé específico._ Cuanta más información proporciones acerca del problema que tienes, mayores serán las posibilidades de obtener una respuesta.
 
-** Incluya la versión de FreeBSD que está ejecutando (existe un lugar donde escribir esta información, vea a continuación) y en qué arquitectura. Debe incluir si se está ejecutando desde una release (por ejemplo, desde un CD-ROM o descarga), o si es desde un sistema mantenido por Subversion (y, si es así, en qué número de revisión se encuentra). Si está usando la rama FreeBSD-CURRENT, esa es la primera pregunta que le harán, porque las correcciones (especialmente para problemas de alto nivel) tienden a aplicarse muy rápidamente, y se espera que los usuarios de FreeBSD-CURRENT se mantengan al día.
-** Incluya qué opciones globales ha especificado en sus ficheros [.filename]#make.conf#, [.filename]#src.conf# y [.filename]#src-env.conf#. Dado el número infinito de opciones, no todas las combinaciones pueden ser totalmente compatibles.
-** Si el problema se puede reproducir fácilmente, incluya información que ayude al desarrollador a reproducirlo por sí mismo. Si se puede hacer una demostración con una entrada específica, incluya un ejemplo con esa entrada, si es posible, e incluya la salida real y la esperada. Si la información es grande o no se puede hacer pública, intente crear un archivo con lo mínimo que muestre el mismo problema y que pueda incluirse en el PR.
-** Si se trata de un problema del kernel, prepárese para proporcionar la siguiente información. (No es necesario incluir esta información por defecto, puesto que lo único que produce es un crecimiento desmesurado de la base de datos, pero sí puede merecer la pena incluir extractos que usted considere importantes):
+** Incluye la versión de FreeBSD que estás ejecutando (existe un lugar donde escribir esta información, lee a continuación) y en qué arquitectura. Debes incluir si se está ejecutando desde una release (por ejemplo, desde un CD-ROM o descarga), o si es desde un sistema mantenido por Git (y, si es así, en qué hash y rama te encuentras). Si estás usando la rama FreeBSD-CURRENT, esa es la primera pregunta que te harán, porque las correcciones (especialmente para problemas de alto nivel) tienden a solucionarse muy rápidamente, y se espera que los usuarios de FreeBSD-CURRENT se mantengan al día.
+** Incluye qué opciones globales has especificado en tus ficheros [.filename]#make.conf#, [.filename]#src.conf#, y [.filename]#src-env.conf#. Dado el número infinito de opciones, no todas las combinaciones podrían ser totalmente compatibles.
+** Si el problema se puede reproducir fácilmente, incluye información que ayude al desarrollador a reproducirlo por sí mismo. Si se puede hacer una demostración con una entrada específica, incluye un ejemplo con esa entrada, si es posible, e incluye la salida real y la esperada. Si la información es grande o no se puede hacer pública, intenta crear un archivo con lo mínimo que muestre el mismo problema y que pueda incluirse en el PR.
+** Si se trata de un problema del kernel, prepárate para proporcionar la siguiente información. (No es necesario incluir esta información por defecto, puesto que lo único que produce es un crecimiento desmesurado de la base de datos, pero sí puede merecer la pena incluir extractos que consideres importantes):
 
-*** la configuración del kernel (incluidos los dispositivos de hardware que ha instalado)
-*** si tiene o no opciones de depuración activadas (como `WITNESS`), y si es así, si el problema persiste cuando se cambia el valor de dichas opciones
+*** la configuración del kernel (incluidos los dispositivos de hardware que has instalado)
+*** si tienes las opciones de depuración activadas (tales como `WITNESS`), y si es así, si el problema persiste cuando cambias esa opción
 *** el texto completo de cualquier backtrace, panic u otra salida por consola, o entradas en [.filename]#/var/log/messages#, si se generó alguna
-*** la salida de `pciconf -l` y partes relevantes de su salida `dmesg` si su problema se relaciona con una pieza específica de hardware
-*** el hecho de que haya leído [.filename]#src/UPDATING# y que su problema no esté listado (seguro que alguien le preguntará sobre este punto)
+*** la salida de `pciconf -l` y las partes relevantes de tu salida de `dmesg` si tu problema está relacionado con un hardware específico
+*** el hecho de que hayas leído [.filename]#src/UPDATING# y que tu problema no esté listado (seguro que alguien te preguntará sobre esto)
 *** si puede o no ejecutar otro kernel de respaldo sin problemas (se trata de descartar problemas relacionados con el hardware, como discos con errores o CPUs con sobrecalentamiento, que pueden confundirse fácilmente con problemas del kernel)
 
-** Si se trata de un problema relacionado con los ports, prepárese para poder proporcionar la información que se muestra a continuación. (No es necesario incluir esta información por defecto, ya que esto solo produce un crecimiento indeseado de la base de datos, pero debe incluir extractos que considere que pueden ser relevantes):
+** Si se trata de un problema relacionado con los ports, prepárate para poder proporcionar la información que se muestra a continuación. (No es necesario incluir esta información por defecto, ya que esto solo produce un crecimiento indeseado de la base de datos, pero debe incluir extractos que consideres que pueden ser relevantes):
 
-*** Qué ports ha instalado
-*** Cualquier variable de entorno que sobrescriba los valores por defecto del archivo [.filename]#bsd.port.mk#, como `PORTSDIR`
-*** El hecho de que ha leído el archivo [.filename]#ports/UPDATING# y que su problema no se encuentra en la lista (puede preguntar a alguien)
+*** qué ports has instalado
+*** cualquier variable de entorno que sobrescribe los valores por defecto en [.filename]#bsd.port.mk#, como `PORTSDIR`
+*** El hecho de que has leído el archivo [.filename]#ports/UPDATING# y que tu problema no se encuentra en la lista (seguro que alguien te lo pregunta)
 
-* _Evitar peticiones de características vagas._ Los PRs del estilo "alguien debería implementar algo que haga esto, aquello y lo de más allá" son informes con pocas probabilidades de obtener resultados positivos. Recuerde, el código fuente se encuentra disponible para todo el mundo, por lo tanto, si desea una característica, ¡la mejor manera de asegurarse de que se incluya es ponerse a trabajar en ella! También tenga en cuenta que para discutir este tipo de problemas resulta más adecuado utilizar la lista `freebsd-questions`, que una entrada en la base de datos de PR, como ya se ha comentado anteriormente.
-* _Asegúrese que nadie más ha enviado un PR similar._ Aunque esto ya se ha mencionado anteriormente, vale la pena repetirlo aquí. Solamente lleva uno o dos minutos utilizar el motor de búsqueda web en https://bugs.freebsd.org/bugzilla/query.cgi[https://bugs.freebsd.org/bugzilla/query.cgi]. (Por supuesto, todo el mundo es culpable de olvidarse de hacerlo de vez en cuando).
-* _Informe un solo problema por informe._ Evite incluir dos o más problemas dentro del mismo informe, a menos que estén relacionados. Al enviar parches, evite agregar múltiples funciones o corregir varios errores en el mismo PR, a menos que estén estrechamente relacionados -- ya que los PR suelen tardar más en resolverse.
-* _Evite peticiones controvertidas._ Si su PR se dirige a un área que ha sido controvertida en el pasado, probablemente debería estar preparado para no solo ofrecer parches, sino también una justificación de por qué los parches son la "forma correcta de hacerlo". Como se avisó anteriormente, una búsqueda meticulosa en las listas de correo utilizando los archivos históricos en https://www.FreeBSD.org/search/#mailinglists[https://www.FreeBSD.org/search/#mailinglists] es siempre una buena opción.
-* _Sea educado._ Practicamente cualquier persona que se encargue de tratar su PR es un voluntario. A nadie le gusta que le digan que tiene que hacer algo cuando ya lo están haciendo por alguna otra motivación que no sea la económica. Es bueno tenerlo en cuenta en todo momento en los proyectos de código abierto.
+* _Evita solicitudes vagas de nuevas funcionalidades._ PRs con la forma "alguien debería implementar algo que haga esto y lo otro" tienen menos probabilidad de obtener resultados que las peticiones específicas. Recuerda, las fuentes están disponible para cualquiera, así que si quieres una funcionalidad, la mejor forma de asegurarte de que se incluye ¡es ponerte a trabajar! Además considera el hecho de que muchas cosas como esta tendrían mejor cabida en una discusión en `freebsd-questions` que en una entrada de la base de datos de PR, como se ha comentado arriba.
+* _Asegúrate de que nadie haya enviado ya un PR similar._ Aunque esto ya se ha mencionado arriba, se repite aquí. Sólo lleva un minuto o dos usar el motor de búsqueda basada en web en https://bugs.freebsd.org/bugzilla/query.cgi[https://bugs.freebsd.org/bugzilla/query.cgi]. (Por supuesto, todos somos culpables de olvidarnos de hacerlo de vez en cuando.)
+* _Reporta un solo problema por informe._ Evita incluir dos o más problemas dentro del mismo informe, a menos que estén relacionados. Al enviar parches, evita agregar múltiples funcionalidades o corregir varios errores en el mismo PR, a menos que estén estrechamente relacionados — esos PRs suelen tardar más en resolverse.
+* _Evita solicitudes controvertidas._ Si tu PR trata sobre un área que ha sido controvertida anteriormente, deberías estar preparado no sólo para ofrecer parches, sino también una justificación sobre por qué los parches son "Lo Que Se Debería Hacer". Como se ha comentado arriba, una búsqueda cuidadosa en las listas de correo utilizando los históricos en https://www.FreeBSD.org/search/#mailinglists[https://www.FreeBSD.org/search/#mailinglists] es siempre una buena preparación.
+* _Sé educado._ Prácticamente cualquier persona que trabaje en tu PR es un voluntario. A nadie le gusta que le digan que tiene que hacer algo cuando ya lo están haciendo por alguna otra motivación que no sea la económica. Es bueno tenerlo en cuenta en todo momento en los proyectos Open Source.
 
 [[pr-writing-before-beginning]]
 == Antes de comenzar
 
-Se aplican consideraciones similares al uso del formulario de envío de PR https://bugs.freebsd.org/bugzilla/enter_bug.cgi[por la aplicación web]. Tenga cuidado con las operaciones de cortar y pegar que puedan cambiar los espacios en blanco u otro formato de texto.
+Se pueden aplicar consideraciones similares al uso del https://bugs.freebsd.org/bugzilla/enter_bug.cgi[formulario de envío de PR basado en web]. Ten cuidado con las operaciones de copiar-y-pegar que podrían cambiar los espacios en blanco u otros formatos de texto.
 
-Finalmente, si el envío es largo, prepare el trabajo sin conexión, de forma que no se pierda nada si hay un problema al enviarlo.
+Finalmente, si el envío es largo, prepara el trabajo sin conexión, de forma que no se pierda nada si hay un problema al enviarlo.
 
 [[pr-writing-attaching-patches]]
 == Adjuntar parches o archivos
 
-Al adjuntar un parche, asegúrese de usar `svn diff` o man:diff[1] con el argumento `-u` para crear un diff unificado, y asegúrese de especificar el número de revisión SVN del repositorio contra el que modificó los archivos, para que los desarrolladores que lean su informe puedan aplicarlos fácilmente. Para problemas relacionados con el kernel o utilidades del sistema base, se prefiere un parche contra FreeBSD-CURRENT (la rama HEAD de Subversion), ya que todo el código nuevo debe aplicarse y probarse allí primero. Después de que se hayan realizado las pruebas adecuadas o importantes, se hará el merge/migración a la rama FreeBSD-STABLE.
+En general, recomendamos utilizar `git format-patch` para generar uno o una serie de diffs unificados contra la rama base (por ejemplo `origin/main`). Los parches generados así incluirían los hashes de Git e incluirán tu nombre y dirección de correo, haciendo más fácil para los committers aplicar tu parche y reconocerte como el autor (usando `git am`). Para cambios menores donde prefieres no usar git, asegúrate de usar man:diff[1] con la opción `-u` para crear un diff unificado, ya que esto dará a los desarrolladores más contexto y hace que el diff sea más legible que otros formatos.
+
+Para problemas con el kernel o utilidades base, es preferible un parche contra FreeBSD-CURRENT (la rama principal en Git) ya que todo el código nuevo se debería aplicar y probar primero ahí. Después de que se hayan hecho las pruebas apropiadas o sustanciales, el código se mergeará/migrará a la rama FreeBSD-STABLE.
 
 Si adjunta un parche como parte del mensaje, en lugar de como adjunto, tenga en cuenta que uno de los problemas más comunes es la tendencia de algunos programas de correo electrónico de mostrar las tabulaciones como espacios, lo cual estropeará por completo todo lo que pretenda que forme parte de un Makefile.
 
-No envíe parches como archivos adjuntos usando `Content-Transfer-Encoding: quoted-printable`. Esto escapará el carácter (character escaping) y todo el parche será inútil.
+No envíes parches como archivos adjuntos usando `Content-Transfer-Encoding: quoted-printable`. Esto hará escapado de caracteres y todo el parche será inútil.
 
-También tenga en cuenta que, incluir pequeños parches en un PR, en general, está bien, especialmente cuando soluciona el problema descrito en el PR, los parches grandes y especialmente el nuevo código que pueda requerir una revisión sustancial antes de realizar el commit deben colocarse en un servidor web o ftp, y la URL debe incluirse en el PR en lugar del parche. Los parches en el correo electrónico tienden a ser destrozados, y cuanto más grande sea el parche, más difícil será para las partes interesadas desenmarañarlo. Además, la publicación de un parche en la web le permite modificarlo sin tener que volver a enviar el parche completo en un follow-up al PR original. Finalmente, los parches grandes simplemente aumentan el tamaño de la base de datos, ya que los PR cerrados no se eliminan, sino que se guardan y simplemente se marcan como completos.
+Ten en cuenta también que, incluir pequeños parches en un PR, en general, está bien, especialmente cuando soluciona el problema descrito en el PR, los parches grandes y especialmente el nuevo código que pueda requerir una revisión sustancial antes de realizar el commit deben colocarse en un servidor web o ftp, y la URL debe incluirse en el PR en lugar del parche. Los parches en el correo electrónico tienden a ser destrozados, y cuanto más grande sea el parche, más difícil será para las partes interesadas desenmarañarlo. Además, la publicación de un parche en la web te permite modificarlo sin tener que volver a enviar el parche completo en un follow-up al PR original. Finalmente, los parches grandes simplemente aumentan el tamaño de la base de datos, ya que los PR cerrados no se eliminan, sino que se guardan y simplemente se marcan como completos.
 
-También debe tener en cuenta que, a menos que se especifique explícitamente lo contrario en su PR o en el propio parche, se asumirá que los parches que envíe se licenciarán en los mismos términos que el archivo original que modificó.
+También debes tener en cuenta que, a menos que se especifique explícitamente lo contrario en su PR o en el propio parche, se asumirá que los parches que envíes se licenciarán en los mismos términos que el archivo original que modificaste.
 
 [[pr-writing-filling-template]]
 == Rellenar el formulario
 
 [NOTE]
 ====
-La dirección de correo electrónico que utilice pasará a ser pública y podrá estar disponible para los spammers. Debe tener implementados procedimientos de manejo de spam o usar una cuenta de correo electrónico temporal. Sin embargo, tenga en cuenta que si no utiliza una cuenta de correo electrónico válida, no podremos hacerle preguntas sobre su PR.
+La dirección de correo electrónico que utilices pasará a ser pública y podrá estar disponible para los spammers. Debes tener implementados procedimientos de manejo de spam o usar una cuenta de correo electrónico temporal. Sin embargo, ten en cuenta que si no utilizas una cuenta de correo electrónico válida, no podremos hacerte preguntas sobre tu PR.
 ====
 
-Cuando presente un error, encontrará los siguientes campos:
+Cuando presentes un error, encontrarás los siguientes campos:
 
-* _Synopsis:_ Rellene este campo con una descripción corta y precisa del problema. El campo debe ser rellenado en inglés, pues es el idioma de comunicación en el proyecto FreeBSD. La sinopsis se utiliza como subject del correo electrónico del informe de problemas, y también se utiliza en los listados y resúmenes de informes de la base de datos; informes de problemas con vagas sinopsis tienden a ser completamente ignorados.
-* _Severity:_ Escoga una de las opciones, `Affects only me (Solo me afecta a mi)`, `Affects some people (Afecta a algunas personas)` o `Affects many people (Afecta a muchas personas)`. No sea exagerado; absténgase de etiquetar su problema `Affects many people (Afecta a muchas personas)` a menos que realmente lo haga. Los desarrolladores de FreeBSD no trabajarán en su problema más rápido si infla su importancia, ya que muchas otras personas han hecho exactamente lo mismo.
-* _Category:_ Elija una categoría apropiada.
-+ 
-Lo primero que debe hacer es decidir en qué parte del sistema se encuentra su problema. Recuerde, FreeBSD es un sistema operativo completo, instala un kernel, la biblioteca estándar, muchos controladores de periféricos y un gran número de utilidades (el "sistema base"). Sin embargo, hay miles de aplicaciones adicionales en la colección de ports. Primero deberá decidir si el problema está en el sistema base o en algo instalado a través de la colección de ports.
-+ 
+* _Summary:_ Rellena este campo con una descripción corta y precisa del problema. El campo debe ser rellenado en inglés, pues es el idioma de comunicación en el proyecto FreeBSD. La sinopsis se utiliza como subject del correo electrónico del informe de problemas, y también se utiliza en los listados y resúmenes de informes de la base de datos; informes de problemas con vagas sinopsis tienden a ser completamente ignorados.
+* _Severity:_ Una de `Affects only me`, `Affects some people` o `Affects many people`. No exageres; contente de etiquetar tu problema como `Affects many people` a menos que realmente sea así. Los desarrolladores de FreeBSD no van a trabajar necesariamente más rápido si inflas su importancia puesto que hay mucha otra gente que ha hecho exactamente eso.
+* _Category:_ Escoge la categoría apropiada.
++
+Lo primero que debes hacer es decidir en qué parte del sistema se encuentra tu problema. Recuerda, FreeBSD es un sistema operativo completo, instala un kernel, la biblioteca estándar, muchos controladores de periféricos y un gran número de utilidades (el "sistema base"). Sin embargo, hay miles de aplicaciones adicionales en la colección de ports. Primero deberás decidir si el problema está en el sistema base o en algo instalado a través de la colección de ports.
++
 Aquí una descripción de las principales categorías:
 
 ** Si hay un problema con el kernel, las bibliotecas (como la biblioteca estándar de C `libc`) o en un controlador de un periférico en el sistema base, en general, utilizará la categoría `kern`. (Hay algunas excepciones; vea más abajo). En general, estas son las cosas que se describen en la sección 2, 3 ó 4 de las páginas del manual.
-** Si el problema es con un binario como man:sh[1] o man:mount[8], primero deberá determinar si estos programas se encuentran en el sistema base o se añadieron a través de la colección de ports. Si no está seguro, puede hacer `whereis _programname_`. La convención de FreeBSD para la colección de ports es instalar todo por debajo de [.filename]#/usr/local#, aunque un administrador del sistema puede sobreescribirlo. Para estos, utilizará la categoría de `ports` (sí, incluso si la categoría del port es `www`; vea más abajo). Si la ubicación es [.filename]#/bin#, [.filename]#/usr/bin#, [.filename]#/sbin#, o [.filename]#/usr/sbin#, es parte del sistema base, y debe usar la categoría `bin`. Estas son todas las cosas que se describen en las secciones 1 u 8 de las páginas del manual.
-** Si cree que el error está en los scripts de inicio `(rc)`, o en algún otro tipo de archivo de configuración no ejecutable, entonces la categoría correcta es `conf` (configuración). Estas son las cosas que se describen en la sección 5 de las páginas del manual.
-** Si ha encontrado un problema en el conjunto de la documentación (artículos, libros, man pages) o en el sitio web, la elección correcta es `docs`.
+** Si el problema tiene que ver con un programa binario como man:sh[1] o man:mount[8], primero necesitarás determinar si estos programas están en el sistema base o se añadieron mediante la Colección de Ports. Si no estás seguro puedes hacer `whereis _programa_`. La convención para la Colección de Ports de FreeBSD es instalar todo bajo [.filename]#/usr/local#, aunque un administrador del sistema puede cambiar este comportamiento. Para estos, usarás la categoría `ports`(sí, incluso si la categoría del port es `www`; lee más abajo). Si se encuentra en [.filename]#/bin#, [.filename]#/usr/bin#, [.filename]#/sbin#, o [.filename]#/usr/sbin#, es parte del sistema base, y deberías usar la categoría `bin`. Estas son todas las cosas que se describen en las secciones 1 o 8 de las páginas de manual.
+** Si crees que el error está en los scripts de inicio `(rc)`, o en algún otro tipo de archivo de configuración no ejecutable, entonces la categoría correcta es `conf` (configuración). Estas son las cosas que se describen en la sección 5 de las páginas del manual.
+** Si has encontrado un problema en el conjunto de documentación (artículos, libros, páginas de manual) o sitio web la opción correcta es `docs`.
 +
 [NOTE]
 ====
-Si tiene un problema con un port llamado `www/_algunnombredeport_`, esto entra en la categoría de `ports`.
+si tienes un problema con un port llamado `www/_nombredelport_`, esto aún así también va en la categoría `ports`.
 ====
-+ 
++
 Hay algunas categorías más especializadas.
 
-** Si el problema se catalogará en `kern` pero estuviera relacionado con el subsistema USB, la elección correcta es `usb`.
-** Si el problema se catalogará en `kern` pero estuviera relacionado con las bibliotecas de threading, la elección correcta es `threads`.
-** Si el problema se catalogará en el sistema base, pero estuviera relacionado con nuestra interpretación de estándares, como POSIX(R), la elección correcta es `standards`.
-** Si está convencido de que el problema solo ocurrirá con la arquitectura del procesador que está utilizando, seleccione una de las categories específicas de la arquitectura: normalmente, `i386` para ordenadores compatibles con Intel en modo 32 bits; `amd64` para máquinas AMD que se ejecutan en modo 64 bits (esto también incluye ordenadores compatibles con Intel que se ejecutan en modo EMT64); y las menos comunes, `arm` o `powerpc`.
+** si el problema podría ir en `kern` pero tiene que ver con el subsistema USB, la opción correcta es `usb`.
+** si el problema podría ir en `kern` pero tiene que ver con las librerías de hilos, la opción correcta es `threads`.
+** si el problema podría ser del sistema base, pero tiene que ver con la conformidad a los estándares como POSIX(R), la opción correcta es `standards`.
+** Si estás convencido de que el problema solo ocurrirá con la arquitectura del procesador que estás utilizando, selecciona una de las categorías específicas de la arquitectura: normalmente, `i386` para ordenadores compatibles con Intel en modo 32 bits; `amd64` para máquinas AMD que se ejecutan en modo 64 bits (esto también incluye ordenadores compatibles con Intel que se ejecutan en modo EMT64); y las menos comunes, `arm` o `powerpc`.
 +
 [NOTE]
 ====
-Estas categorías se utilizan con frecuencia para los problemas "No lo sé". En lugar de suponer, utilice `misc`.
+Estas categorías a menudo son usadas erróneamente para problemas tipo "no lo sé". En lugar de especular, utiliza simplemente `misc`.
 ====
 +
 .Uso correcto de la categoría de arquitectura específica
 [example]
 ====
-
-Tiene un ordenador común (PC-based machine), y cree que ha encontrado un problema específico para un conjunto de chips o una placa base en particular: `i386` es la categoría correcta.
+Tienes una máquina normal tipo PC y piensas que has encontrado un problema específico de un chipset o una placa base particular: `i386` es la categoría correcta.
 ====
 +
 .Uso incorrecto de la categoría de arquitectura específica
 [example]
 ====
-
-Está teniendo un problema con una tarjeta periférica adicional en un bus común, o un problema con un tipo particular de unidad de disco duro: en este caso, probablemente afecte a más de una arquitectura, y `kern` es la categoría correcta.
+Estás teniendo un problema con una tarjeta periférica adicional en un bus común, o un problema con un tipo particular de unidad de disco duro: en este caso, probablemente afecte a más de una arquitectura, y `kern` es la categoría correcta.
 ====
-** Si realmente no sabe dónde está el problema (o la explicación no parece encajar en los anteriores), use la categoría `misc`. Antes de hacerlo, es posible que primero desee solicitar ayuda en la http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions[lista de correo de preguntas generales de FreeBSD]. Es posible que le indiquen que una de las categorías ya existentes es mejor opción.
-* _Environment:_ Esto debe describir, con la mayor precisión posible, el entorno en el que se ha observado el problema. Esto incluye la versión del sistema operativo, la versión del programa o archivo específico que contiene el problema y cualquier otro elemento relevante como la configuración del sistema, otro software instalado que influya en el problema, etc. -- simplemente todo lo que un desarrollador necesita saber para reconstruir el entorno en el que se produce el problema.
-* _Description:_ Una descripción completa y precisa del problema que está experimentando. Intente evitar especular sobre las posibles causas del problema a menos que se tenga la seguridad de que el camino descrito es el correcto, ya que puede inducir a un desarrollador a hacer suposiciones incorrectas sobre el problema. Debe incluir las acciones que hay que realizar para reproducir el problema. Si conoce alguna solución, inclúyala. No solo ayuda a otras personas con el mismo problema a solucionarlo, sino que también puede ayudar a un desarrollador a entender la causa del problema.
+** Si realmente no sabes dónde está el problema (o la explicación no parece adecuarse a ninguna de las de arriba), utiliza la categoría `misc`. Antes de hacerlo, podrías querer pedir ayuda primero en la {freebsd-questions}. Te podrían aconsejar que una de las categorías existentes es realmente una mejor opción.
+* _Environment:_ Esto debería describir, con la mayor precisión posible, el entorno en el que se ha observado el problema. Esto incluye la versión del sistema operativo, la versión del programa o archivo específico que contiene el problema y cualquier otro elemento relevante como la configuración del sistema, otro software instalado que influya en el problema, etc. — simplemente todo lo que un desarrollador necesita saber para reconstruir el entorno en el que se produce el problema.
+* _Description:_ Una descripción completa y precisa del problema que estás experimentando. Intenta evitar especular sobre las posibles causas del problema a menos que se tenga la seguridad de que el camino descrito es el correcto, ya que puede inducir a un desarrollador a hacer suposiciones incorrectas sobre el problema. Debería incluir las acciones que hay que realizar para reproducir el problema. Si conoces alguna solución, inclúyela. No solo ayuda a otras personas con el mismo problema a solucionarlo, sino que también puede ayudar a un desarrollador a entender la causa del problema.
 
 [[pr-followup]]
 == Follow-up
 
-Una vez que se haya enviado el informe de problemas, recibirá una confirmación por correo electrónico que incluirá el número de seguimiento que se asignó a su informe de problemas y una URL que puede usar para verificar su estado. Con un poco de suerte, alguien se interesará en su problema e intentará solucionarlo o, según sea el caso, explicará por qué no es un problema. Se le notificará automáticamente de cualquier cambio de estado y recibirá copias de los comentarios o parches que alguien pueda adjuntar al registro de auditoría de su informe de problemas.
+Una vez que se haya enviado el informe de problemas, recibirás una confirmación por correo electrónico que incluirá el número de seguimiento que se asignó a tu informe de problemas y una URL que puedes usar para verificar su estado. Con un poco de suerte, alguien se interesará en tu problema e intentará solucionarlo o, según sea el caso, explicará por qué no es un problema. Se te notificará automáticamente de cualquier cambio de estado y recibirás copias de los comentarios o parches que alguien pueda adjuntar al registro de auditoría de tu informe de problemas.
 
-Si alguien le solicita información adicional, o si recuerda o descubre algo que no mencionó en el informe inicial, por favor, envíe un follow-up. La razón número uno para que un error no se arregle es la falta de comunicación con el usario que creó el error. La forma más fácil es usar la opción de comentarios en la página web de cada PR, a la que puede acceder desde la https://bugs.freebsd.org/bugzilla/query.cgi[página de búsqueda de PR].
+Si alguien te solicita información adicional, o si recuerdas o descubres algo que no mencionaste en el informe inicial, por favor, envía un follow-up. La razón número uno para que un error no se arregle es la falta de comunicación con el usuario que creó el error. La forma más fácil es usar la opción de comentarios en la página web de cada PR, a la que puedes acceder desde la https://bugs.freebsd.org/bugzilla/query.cgi[página de búsqueda de PRs].
 
-Si el informe de problemas permanece abierto una vez que dicho problema ha desaparecido, solo agregue un comentario que indique que el informe de problemas se puede cerrar y, a ser posible, explique cómo o cuándo se solucionó el problema.
+Si el informe de problemas permanece abierto una vez que dicho problema ha desaparecido, solo agrega un comentario que indique que el informe de problemas se puede cerrar y, a ser posible, explica cómo o cuándo se solucionó el problema.
 
 A veces hay un retraso de una o dos semanas en las cuales el informe del problema está sin cambios, sin asignar, ni comentado por nadie. Esto puede suceder cuando hay una acumulación de informes de problemas o durante la temporada de vacaciones. Cuando un informe de problemas no ha recibido atención después de varias semanas, vale la pena encontrar a un committer que esté interesado en trabajar en él.
 
 Hay varias formas de hacerlo, lo ideal es el orden siguiente, con algunos días entre cada intento:
 
-* Encuentre la lista de correo de FreeBSD que sea relevante para el informe de problemas en extref:{handbook}eresources[la lista del manual, eresources-mail] y envíe un mensaje a esa lista preguntando por asistencia o comentarios sobre el informe de problemas.
-* Únase a los canales de IRC relevantes. Aquí un listado parcial: https://wiki.freebsd.org/IrcChannels[]. Informe a las personas en ese canal sobre el informe del problema y solicite asistencia. Sea paciente y permanezca en el canal después de la publicación, para que las personas de diferentes zonas horarias de todo el mundo tengan la oportunidad de ponerse al día.
-* Encuentre a committers interesados en el problema que reportó. Si el problema estaba en una herramienta, binario, port, documento o un fichero de código fuente en particular, verifique el http://svnweb.FreeBSD.org[repositorio SVN]. Localice a los últimos committers que realizaron cambios sustanciales en el archivo e intente acceder a ellos a través de IRC o correo electrónico. Puede encontrar una lista de los committers y sus correos electrónicos en el artículo extref:{contributors}[Colaboradores de FreeBSD].
+* Envía un e-mail a extref:{handbook}eresources/[la lista apropiada, eresources-summary] buscando comentarios sobre el informe.
+* Únete a los canales de IRC relevantes. Se puede encontrar un listado parcial aquí: https://wiki.freebsd.org/IrcChannels[]. Informa a la gente en el canal acerca del informe del problema y pide ayuda. Sé paciente y mantente en el canal después de preguntar, de forma que la gente de diferentes zonas horarias alrededor del mundo tenga una oportunidad para ponerse al día.
+* Encuentra committers interesados en el problema que se ha reportado. Si era sobre una herramienta, binario, port, documento o fichero de fuentes particular, comprueba el https://cgit.FreeBSD.org[Repositorio Git]. Localiza los últimos committers que hicieron cambios sustanciales al fichero y trata de ponerte en contacto con ellos vía IRC o email. Una lista de committers junto con sus emails se puede encontrar en el artículo extref:{contributors}[Colaboradores de FreeBSD].
 
-Recuerde que estas personas son voluntarios, al igual que los maintainers y usuarios, por lo que es posible que no estén disponibles de inmediato para ayudar con el informe del problema. La paciencia y la constancia en los seguimientos son altamente recomendadas y apreciadas. Con el suficiente cuidado y esfuerzo dedicado al proceso de seguimiento, encontrar un committer para encargarse del informe del problema es solo cuestión de tiempo.
+Recuerda que estas personas son voluntarios, al igual que los mantenedores y usuarios, por lo que es posible que no estén disponibles de inmediato para ayudar con el informe del problema. La paciencia y la constancia en los seguimientos son altamente recomendadas y apreciadas. Con el suficiente cuidado y esfuerzo dedicado al proceso de seguimiento, encontrar un committer para encargarse del informe del problema es solo cuestión de tiempo.
 
 [[pr-problems]]
 == Si hay problemas
 
-Si ha encontrado un problema con el sistema de errores, ¡presente un error! Hay una categoría exacta para este propósito. Si no puede hacerlo, póngase en contacto con los encargados de los errores en mailto:bugmeister@FreeBSD.org[bugmeister@FreeBSD.org].
+Si encontraste un problema en el sistema de bugs, ¡abre un informe de error! Hay una categoría exactamente para este propósito. Si no puedes hacerlo, contacta con los domadores de bugs en mailto:bugmeister@FreeBSD.org[bugmeister@FreeBSD.org].
 
 [[pr-further]]
-== Lecturas adicionales
+== Otras Lecturas
 
-A continuación se muestra una lista de recursos relacionados con la escritura adecuada de informes y con el procesamiento de dichos informes. No pretende ser una completa enumeración.
+Esta es una lista de recursos relacionados con la escritura y procesamiento adecuados de informes de error. No pretende ser una lista completa.
 
-* https://github.com/smileytechguy/reporting-bugs-effectively/blob/master/ENGLISH.md[Cómo informar errores de forma efectiva]--un excelente ensayo por Simon G. Tatham sobre la redacción de informes de problemas (el texto no es específico sobre FreeBSD).
-* extref:{pr-guidelines}[Guía para el manejo de informes de problemas]--contiene una información valiosa sobre cómo los informes de problemas son manejados por los desarrolladores de FreeBSD.
+* https://github.com/smileytechguy/reporting-bugs-effectively/blob/master/ENGLISH.md[How to Report Bugs Effectively]-un ensayo excelente de Simon G. Tatham sobre cómo componer informes de error útiles (no específico de FreeBSD).
+* extref:{pr-guidelines}[Problem Report Handling Guidelines]-conocimiento valioso sobre cómo los desarrolladores de FreeBSD se encargan de los informes de problemas.
diff --git a/documentation/content/es/articles/problem-reports/_index.po b/documentation/content/es/articles/problem-reports/_index.po
new file mode 100644
index 0000000000..2d57729888
--- /dev/null
+++ b/documentation/content/es/articles/problem-reports/_index.po
@@ -0,0 +1,1445 @@
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR The FreeBSD Project
+# This file is distributed under the same license as the FreeBSD Documentation package.
+# Fernando  Apesteguía <fernando.apesteguia@gmail.com>, 2021, 2022.
+msgid ""
+msgstr ""
+"Project-Id-Version: FreeBSD Documentation VERSION\n"
+"POT-Creation-Date: 2022-07-07 23:23-0300\n"
+"PO-Revision-Date: 2022-10-13 11:43+0000\n"
+"Last-Translator: Fernando  Apesteguía <fernando.apesteguia@gmail.com>\n"
+"Language-Team: Spanish <https://translate-dev.freebsd.org/projects/"
+"documentation/articlesproblem-reports_index/es/>\n"
+"Language: es\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=2; plural=n != 1;\n"
+"X-Generator: Weblate 4.10.1\n"
+
+#. type: YAML Front Matter: description
+#: documentation/content/en/articles/problem-reports/_index.adoc:1
+#, no-wrap
+msgid "How to best formulate and submit a problem report to the FreeBSD Project"
+msgstr ""
+"Cómo realizar y enviar informes de problemas para el proyecto FreeBSD de la "
+"mejor forma posible"
+
+#. type: Title =
+#: documentation/content/en/articles/problem-reports/_index.adoc:1
+#: documentation/content/en/articles/problem-reports/_index.adoc:11
+#, no-wrap
+msgid "Writing FreeBSD Problem Reports"
+msgstr "Escribiendo Informes de Problemas de FreeBSD"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:44
+msgid "Abstract"
+msgstr "Resumen"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:46
+msgid ""
+"This article describes how to best formulate and submit a problem report to "
+"the FreeBSD Project."
+msgstr ""
+"Este artículo describe cómo realizar y enviar informes de problemas para el "
+"Proyecto FreeBSD de la mejor forma posible."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:48
+msgid "'''"
+msgstr "'''"
+
+#. type: Title ==
+#: documentation/content/en/articles/problem-reports/_index.adoc:52
+#, no-wrap
+msgid "Introduction"
+msgstr "Introducción"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:56
+msgid ""
+"One of the most frustrating experiences one can have as a software user is "
+"to submit a problem report only to have it summarily closed with a terse and "
+"unhelpful explanation like \"not a bug\" or \"bogus PR\".  Similarly, one of "
+"the most frustrating experiences as a software developer is to be flooded "
+"with problem reports that are not really problem reports but requests for "
+"support, or that contain little or no information about what the problem is "
+"and how to reproduce it."
+msgstr ""
+"Una de las experiencias más frustrantes que uno puede tener como usuario de "
+"software es enviar un informe de problemas solo para que se cierre "
+"sumariamente con una explicación breve e inútil como \"no es un error\" o "
+"\"PR erróneo\". De manera similar, una de las experiencias más frustrantes "
+"que puede experimentar un desarrollador de aplicaciones consiste en verse "
+"inundado por una cantidad ingente de informes de problemas que en realidad "
+"vienen a ser solicitudes de soporte o ayuda, o que contienen poca o ninguna "
+"información sobre cual es el problema y cómo reproducirlo."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:59
+msgid ""
+"This document attempts to describe how to write good problem reports.  What, "
+"one asks, is a good problem report? Well, to go straight to the bottom line, "
+"a good problem report is one that can be analyzed and dealt with swiftly, to "
+"the mutual satisfaction of both user and developer."
+msgstr ""
+"Este documento intenta describir cómo escribir buenos informes de problemas. "
+"¿Qué, te preguntarás, es un buen informe de problemas? Bien, para ir "
+"directos al grano, un buen informe de problemas es aquél que se puede "
+"analizar y tratar rápidamente, para mutua satisfacción del usuario y del "
+"desarrollador."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:61
+msgid ""
+"Although the primary focus of this article is on FreeBSD problem reports, "
+"most of it should apply quite well to other software projects."
+msgstr ""
+"Aunque el objetivo principal de este artículo se centra en los informes de "
+"problemas de FreeBSD, la mayoría de los conceptos se pueden aplicar bastante "
+"bien en otros proyectos de software."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:64
+msgid ""
+"Note that this article is organized thematically, not chronologically.  Read "
+"the entire document before submitting a problem report, rather than treating "
+"it as a step-by-step tutorial."
+msgstr ""
+"Ten en cuenta que este artículo está organizado temáticamente, no "
+"cronológicamente. Lee todo el documento antes de enviar un informe de "
+"problemas, en lugar de tratarlo como un tutorial paso a paso."
+
+#. type: Title ==
+#: documentation/content/en/articles/problem-reports/_index.adoc:66
+#, no-wrap
+msgid "When to Submit a Problem Report"
+msgstr "Cuándo Enviar Informes de Problemas"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:72
+msgid ""
+"There are many types of problems, and not all of them should engender a "
+"problem report.  Of course, nobody is perfect, and there will be times when "
+"what seems to be a bug in a program is, in fact, a misunderstanding of the "
+"syntax for a command or a typographical error in a configuration file "
+"(though that in itself may sometimes be indicative of poor documentation or "
+"poor error handling in the application).  There are still many cases where "
+"submitting a problem report is clearly _not_ the right course of action, and "
+"will only serve to frustrate both the submitter and the developers.  "
+"Conversely, there are cases where it might be appropriate to submit a "
+"problem report about something else than a bug-an enhancement or a new "
+"feature, for instance."
+msgstr ""
+"Hay muchos tipos de problemas y no todos ellos merecen la creación de un "
+"informe de problemas. Por supuesto, nadie es perfecto, y habrá ocasiones en "
+"que lo que parece ser un error en un programa es, de hecho, un malentendido "
+"de la sintaxis de un comando o un error tipográfico en un archivo de "
+"configuración (aunque en este último caso podría tratarse de un indicador de "
+"documentación escasa o que la aplicación peca de una gestión de errores "
+"defectuosa). Incluso teniendo estos aspectos en cuenta existen varios casos "
+"en los cuales el envío de un informe de problemas resulta claramente _no "
+"ser_ la mejor forma de proceder y solo servirá para frustrar tanto al "
+"remitente como a los desarrolladores. Por el contrario, hay casos en los que "
+"podría ser apropiado enviar un informe de problemas sobre algo más que un "
+"error: una mejora o una nueva característica, por ejemplo."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:76
+msgid ""
+"So how does one determine what is a bug and what is not? As a simple rule of "
+"thumb, the problem is _not_ a bug if it can be expressed as a question "
+"(usually of the form \"How do I do X?\" or \"Where can I find Y?\").  It is "
+"not always quite so black and white, but the question rule covers a large "
+"majority of cases.  When looking for an answer, consider posing the question "
+"to the {freebsd-questions}."
+msgstr ""
+"Entonces ¿cómo determinar lo que es un bug y lo que no? Una regla sencilla "
+"es que el problema _no_ es un bug si se puede expresar como una pregunta ("
+"normalmente de la forma \"¿Cómo hago X?\" o \"¿Dónde puedo encontrar Y?\"). "
+"No siempre todo es blanco o negro, pero la regla de la pregunta cubre una "
+"gran mayoría de los casos. Cuando estés buscando una respuesta, considera "
+"hacer la pregunta en la {freebsd-questions}."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:78
+msgid ""
+"Consider these factors when submitting PRs about ports or other software "
+"that is not part of FreeBSD itself:"
+msgstr ""
+"Ten en cuenta estos factores al enviar PRs sobre ports u otro software que "
+"no sea parte de FreeBSD:"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:80
+msgid ""
+"Please do not submit problem reports that simply state that a newer version "
+"of an application is available. Ports maintainers are automatically notified "
+"by portscout when a new version of an application becomes available. Actual "
+"patches to update a port to the latest version are welcome."
+msgstr ""
+"Por favor, no envíes informes de problemas que simplemente indiquen la "
+"disponibilidad de una nueva versión de una aplicación. Los maintainers de "
+"ports son notificados automáticamente por portscout cuando una nueva versión "
+"de una aplicación esta disponible. Los parches para actualizar un port a la "
+"última versión son bien recibidos."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:81
+msgid ""
+"For unmaintained ports (`MAINTAINER` is `ports@FreeBSD.org`), a PR without "
+"an included patch is unlikely to get picked up by a committer. To become the "
+"maintainer of an unmaintained port, submit a PR with the request (patch "
+"preferred but not required)."
+msgstr ""
+"Para ports sin mantener (`MAINTAINER` es `ports@FreeBSD.org`), un PR sin un "
+"parche incluido tiene pocas posibilidades de ser cogido por un committer. "
+"Para convertirte en el maintainer de un port sin mantenedor, envía un PR con "
+"la petición (y con el parche preferentemente aunque no es obligatorio)."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:82
+msgid ""
+"In either case, following the process described in extref:{porters-handbook}"
+"upgrading/[Porter's Handbook] will yield the best results. (You might also "
+"wish to read extref:{contributing}[Contributing to the FreeBSD Ports "
+"Collection, ports-contributing].)"
+msgstr ""
+"En cualquier caso, seguir el proceso descrito en el extref:{porters-handbook}"
+"upgrading/[Porter's Handbook] ofrecerá los mejores resultados. (También "
+"podrías querer leer extref:{contributing}[Contribuyendo a la Colección de "
+"Ports de FreeBSD, ports-contributing].)"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:87
+msgid ""
+"A bug that cannot be reproduced can rarely be fixed.  If the bug only "
+"occurred once and you cannot reproduce it, and it does not seem to happen to "
+"anybody else, chances are none of the developers will be able to reproduce "
+"it or figure out what is wrong.  That does not mean it did not happen, but "
+"it does mean that the chances of your problem report ever leading to a bug "
+"fix are very slim.  To make matters worse, often these kinds of bugs are "
+"actually caused by failing hard drives or overheating processors - you "
+"should always try to rule out these causes, whenever possible, before "
+"submitting a PR."
+msgstr ""
+"Un error que no se puede reproducir rara vez se podrá arreglar. Si el error "
+"solo ocurrió una vez y no puedes reproducirlo, y no parece que le ocurra a "
+"nadie más, es probable que ninguno de los desarrolladores pueda reproducirlo "
+"o descubrir qué es lo que está mal. Eso no significa que no haya ocurrido, "
+"significa que las posibilidades de que tu informe de problemas lleve a la "
+"corrección del error son muy escasas. Para empeorar las cosas, a menudo, "
+"este tipo de errores son en realidad causados por fallos en los discos duros "
+"o procesadores con sobrecalentamiento, siempre debes intentar descartar "
+"estas causas, siempre que sea posible, antes de enviar un PR."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:89
+msgid ""
+"Next, to decide to whom you should file your problem report, you need to "
+"understand that the software that makes up FreeBSD is composed of several "
+"different elements:"
+msgstr ""
+"A continuación, para decidir a quién debe presentar su informe de problemas, "
+"debes comprender que el software que compone FreeBSD está compuesto de "
+"varios elementos diferentes:"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:91
+msgid ""
+"Code in the base system that is written and maintained by FreeBSD "
+"contributors, such as the kernel, the C library, and the device drivers "
+"(categorized as `kern`); the binary utilities (`bin`); the manual pages and "
+"documentation (`docs`); and the web pages (`www`). All bugs in these areas "
+"should be reported to the FreeBSD developers."
+msgstr ""
+"El código en el sistema base que escriben y mantienen los colaboradores de "
+"FreeBSD, como el kernel, la biblioteca de C y los controladores de "
+"dispositivos (categorizados como `kern`); las utilidades binarias (`bin`); "
+"las páginas del manual y documentación (`docs`); y las páginas web (`www`). "
+"Todos los errores en estas áreas deben informarse a los desarrolladores de "
+"FreeBSD."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:92
+msgid ""
+"Code in the base system that is written and maintained by others, and "
+"imported into FreeBSD and adapted. Examples include man:clang[1], and man:"
+"sendmail[8]. Most bugs in these areas should be reported to the FreeBSD "
+"developers; but in some cases they may need to be reported to the original "
+"authors instead if the problems are not FreeBSD-specific."
+msgstr ""
+"Código en el sistema base que es escrito y mantenido por otros, e importado "
+"y adaptado a FreeBSD. Ejemplos de esto son man:clang[1], y man:sendmail[8]. "
+"La mayoría de los errores en estas áreas deberían ser reportados a los "
+"desarrolladores de FreeBSD; pero en algunos casos deberían ser reportados a "
+"los autores originales si los problemas no son específicos de FreeBSD."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:93
+msgid ""
+"Individual applications that are not in the base system but are instead part "
+"of the FreeBSD Ports Collection (category `ports`). Most of these "
+"applications are not written by FreeBSD developers; what FreeBSD provides is "
+"merely a framework for installing the application. Therefore, only report a "
+"problem to the FreeBSD developers when the problem is believed to be FreeBSD-"
+"specific; otherwise, report it to the authors of the software."
+msgstr ""
+"Las aplicaciones individuales que no están en el sistema base, sino que "
+"forman parte de la colección de ports de FreeBSD (categoría `ports`). La "
+"mayoría de estas aplicaciones no están escritas por los desarrolladores de "
+"FreeBSD; lo que proporciona FreeBSD es simplemente un framework para "
+"instalar la aplicación. Por lo tanto, informa de un problema a los "
+"desarrolladores de FreeBSD sólo cuando creas que el problema es específico "
+"de FreeBSD; de lo contrario, repórtalo a los autores del software."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:96
+msgid ""
+"Then, ascertain whether the problem is timely.  There are few things that "
+"will annoy a developer more than receiving a problem report about a bug she "
+"has already fixed."
+msgstr ""
+"Después, averigua si es un problema puntual. Existen pocas cosas que "
+"molesten más a un desarrollador que recibir un informe de problemas sobre un "
+"error que ya ha solucionado."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:100
+msgid ""
+"If the problem is in the base system, first read the FAQ section on extref:"
+"{faq}[FreeBSD versions, latest-version], if you are not already familiar "
+"with the topic.  It is not possible for FreeBSD to fix problems in anything "
+"other than certain recent branches of the base system, so filing a bug "
+"report about an older version will probably only result in a developer "
+"advising you to upgrade to a supported version to see if the problem still "
+"recurs.  The Security Officer team maintains the link:https://www.FreeBSD."
+"org/security/[list of supported versions]."
+msgstr ""
+"Si el problema es en el sistema base, primero lee la sección FAQ de "
+"extref:{faq}[FreeBSD versions, latest-version], si no estás familiarizado "
+"con el tema. Para FreeBSD no es posible arreglar problemas en otra cosa que "
+"no sean las ramas más recientes del sistema base, de forma que reportar un "
+"error acerca de una versión más antigua probablemente resulte en un "
+"desarrollador que te aconseja actualizarte a una versión soportada para ver "
+"si el problema sigue ocurriendo. El equipo del Security Officer mantiene la "
+"link:https://www.FreeBSD.org/security/[lista de versiones soportadas]."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:103
+msgid ""
+"If the problem is in a port, consider filing a bug with the upstream.  The "
+"FreeBSD Project can not fix all bugs in all software."
+msgstr ""
+"Si el problema está en un port, considera enviar el error al proyecto "
+"original (upstream). El Proyecto FreeBSD no puede corregir todos los errores "
+"en todo el software."
+
+#. type: Title ==
+#: documentation/content/en/articles/problem-reports/_index.adoc:105
+#, no-wrap
+msgid "Preparations"
+msgstr "Preparativos"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:111
+msgid ""
+"A good rule to follow is to always do a background search before submitting "
+"a problem report.  Maybe the problem has already been reported; maybe it is "
+"being discussed on the mailing lists, or recently was; it may even already "
+"be fixed in a newer version than what you are running.  You should therefore "
+"check all the obvious places before submitting your problem report.  For "
+"FreeBSD, this means:"
+msgstr ""
+"Una buena regla que se puede seguir consiste en realizar siempre una "
+"búsqueda antes de enviar un informe de problemas. Quizá nuestro problema ya "
+"ha sido reportado; quizá se está discutiendo en las listas de correo o fue "
+"discutido hace poco; incluso puede que ya esté arreglado en una versión más "
+"nueva que la que estás ejecutando. Por lo tanto, se deben consultar los "
+"sitios y fuentes más obvias antes de proceder con el envío del informe de "
+"errores. En FreeBSD, esto significa:"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:113
+msgid ""
+"The FreeBSD extref:{faq}[Frequently Asked Questions] (FAQ) list. The FAQ "
+"attempts to provide answers for a wide range of questions, such as those "
+"concerning extref:{faq}[hardware compatibility, hardware], extref:{faq}[user "
+"applications, applications], and extref:{faq}[kernel configuration, "
+"kernelconfig]."
+msgstr ""
+"La lista extref:{faq}[Frequently Asked Questions] (FAQ) de FreeBSD. La FAQ "
+"intenta proporcionar respuestas para un gran rango de preguntas como las que "
+"tienen que ver con extref:{faq}[compatibilidad de hardware, hardware], "
+"extref:{faq}[aplicaciones de usuario, applications], y extref:{faq}["
+"configuración del kernel, kernelconfig]."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:114
+msgid ""
+"The extref:{handbook}eresources/[mailing lists, eresources-mail]-if you are "
+"not subscribed, use https://www.FreeBSD.org/search/#mailinglists[the "
+"searchable archives] on the FreeBSD web site. If the problem has not been "
+"discussed on the lists, you might try posting a message about it and waiting "
+"a few days to see if someone can spot something that has been overlooked."
+msgstr ""
+"Las extref:{handbook}eresources/[listas de correo, eresources-mail]- si "
+"todavía no estás suscrito, usa https://www.FreeBSD.org/search/#mailinglists["
+"la búsqueda del histórico] en el sitio web de FreeBSD. Si el problema no ha "
+"sido discutido en las listas, podrías probar a mandar un mensaje sobre ello "
+"y esperar unos días a ver si alguien se fija en algo que haya sido pasado "
+"por alto."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:115
+msgid ""
+"Optionally, the entire web-use your favorite search engine to locate any "
+"references to the problem. You may even get hits from archived mailing lists "
+"or newsgroups you did not know of or had not thought to search through."
+msgstr ""
+"Opcionalmente, toda la web: utiliza tu motor de búsqueda favorito para "
+"localizar cualquier referencia al problema. Incluso puedes obtener listas de "
+"correo archivadas o grupos de noticias que no conocías o en los que no "
+"habías pensado buscar."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:116
+msgid ""
+"Next, the searchable https://bugs.freebsd.org/bugzilla/query.cgi[FreeBSD PR "
+"database] (Bugzilla). Unless the problem is recent or obscure, there is a "
+"fair chance it has already been reported."
+msgstr ""
+"Después, la https://bugs.freebsd.org/bugzilla/query.cgi[base de datos de PR "
+"de FreeBSD] (Bugzilla) en la que se puede buscar. A menos que el problema "
+"sea reciente u oscuro, hay buenas posibilidades de que ya haya sido "
+"reportado."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:117
+msgid ""
+"Most importantly, attempt to see if existing documentation in the source "
+"base addresses your problem."
+msgstr ""
+"Lo más importante, se debería intentar comprobar si la documentación "
+"existente en el código fuente del programa puede resolver el problema."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:120
+msgid ""
+"For the base FreeBSD code, you should carefully study the contents of [."
+"filename]#/usr/src/UPDATING# on your system or the latest version at https://"
+"cgit.freebsd.org/src/tree/UPDATING[https://cgit.freebsd.org/src/tree/"
+"UPDATING].  (This is vital information if you are upgrading from one version "
+"to another-especially if you are upgrading to the FreeBSD-CURRENT branch)."
+msgstr ""
+"Para el código base de FreeBSD, deberías estudiar detenidamente el contenido "
+"de [.filename]#/usr/src/UPDATING# de tu sistema o la última versión en "
+"https://cgit.freebsd.org/src/tree/UPDATING[https://cgit.freebsd.org/src/tree/"
+"UPDATING]. (Es información vital si estás actualizando de una versión a otra "
+"- especialmente si estás actualizando la rama FreeBSD-CURRENT)."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:123
+msgid ""
+"However, if the problem is in something that was installed as a part of the "
+"FreeBSD Ports Collection, you should refer to [.filename]#/usr/ports/"
+"UPDATING# (for individual ports) or [.filename]#/usr/ports/CHANGES# (for "
+"changes that affect the entire Ports Collection).  https://cgit.freebsd.org/"
+"ports/tree/UPDATING[https://cgit.freebsd.org/ports/tree/UPDATING] and "
+"https://cgit.freebsd.org/ports/tree/CHANGES[https://cgit.freebsd.org/ports/"
+"tree/CHANGES] are also available via cgit."
+msgstr ""
+"Sin embargo, si el problema está en algo que ha sido instalado como parte de "
+"la Colección de Ports de FreeBSD, deberías mirar en [.filename]#/usr/ports/"
+"UPDATING# (para ports individuales) o [.filename]#/usr/ports/CHANGES# (para "
+"cambios que afectan a toda la Colección de Ports). https://cgit.freebsd.org/"
+"ports/tree/UPDATING[https://cgit.freebsd.org/ports/tree/UPDATING] y "
+"https://cgit.freebsd.org/ports/tree/CHANGES[https://cgit.freebsd.org/ports/"
+"tree/CHANGES] también están disponibles vía cgit."
+
+#. type: Title ==
+#: documentation/content/en/articles/problem-reports/_index.adoc:125
+#, no-wrap
+msgid "Writing the Problem Report"
+msgstr "Escribiendo el informe de problemas"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:129
+msgid ""
+"Now that you have decided that your issue merits a problem report, and that "
+"it is a FreeBSD problem, it is time to write the actual problem report.  "
+"Before we get into the mechanics of the program used to generate and submit "
+"PRs, here are some tips and tricks to help make sure that your PR will be "
+"most effective."
+msgstr ""
+"Ahora que has decidido que tu problema merece un informe de problemas y que "
+"es un problema de FreeBSD, es el momento de escribir el informe de problemas "
+"propiamente dicho. Antes de pasar a describir los mecanismos utilizados por "
+"el programa encargado de generar y enviar los PRs, aquí hay algunos consejos "
+"y trucos que te ayudarán a garantizar de que tu PR sea más efectivo."
+
+#. type: Title ==
+#: documentation/content/en/articles/problem-reports/_index.adoc:131
+#, no-wrap
+msgid "Tips and Tricks for Writing a Good Problem Report"
+msgstr "Consejos y trucos para escribir un buen informe de problemas"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:134
+msgid ""
+"_Do not leave the \"Summary\" line empty._ The PRs go both onto a mailing "
+"list that goes all over the world (where the \"Summary\" is used for the "
+"`Subject:` line), but also into a database. Anyone who comes along later and "
+"browses the database by synopsis, and finds a PR with a blank subject line, "
+"tends just to skip over it. Remember that PRs stay in this database until "
+"they are closed by someone; an anonymous one will usually just disappear in "
+"the noise."
+msgstr ""
+"_No dejes la línea \"Summary\" vacía._ Los PRs van tanto a una lista de "
+"correo que va a todo el mundo (donde \"Summary\" se utiliza para la línea "
+"`Subject:`), pero también a una base de datos. Cualquiera que tiempo después "
+"aparece y busca en la base de datos por sinopsis y encuentra un PR con la "
+"línea de tema en blanco, tiende a saltársela. Recuerda que los PR se "
+"mantienen en esta base de datos hasta que alguien los cierra; una anónima "
+"desaparecerá entre el ruido."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:135
+msgid ""
+"_Avoid using a weak \"Summary\" line._ You should not assume that anyone "
+"reading your PR has any context for your submission, so the more you "
+"provide, the better. For instance, what part of the system does the problem "
+"apply to? Do you only see the problem while installing, or while running? To "
+"illustrate, instead of `Summary: portupgrade is broken`, see how much more "
+"informative this seems: `Summary: port ports-mgmt/portupgrade coredumps on -"
+"current`. (In the case of ports, it is especially helpful to have both the "
+"category and portname in the \"Summary\" line.)"
+msgstr ""
+"_Evita el uso de líneas \"Summary\" débiles._ No deberías asumir que alguien "
+"que lee tu PR tiene contexto acerca del mismo, así que cuando más "
+"proporciones, mejor. Por ejemplo, ¿a qué parte del sistema se refiere el "
+"problema?¿Sólo ves el problema al instalar o mientras ejecutas? Para "
+"ilustrar este punto, en lugar de `Summary: portupgrade está roto`, fíjate "
+"cómo esto es más informativo: `Summary: el port ports-mgmt/portupgrade "
+"genera un core en -current`. (En el caso de los ports, es especialmente útil "
+"tener tanto la categoría como el port en la línea \"Summary\".)"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:136
+msgid ""
+"_If you have a patch, say so._ A PR with a patch included is much more "
+"likely to be looked at than one without. Please set the `patch` Keyword in "
+"Bugzilla."
+msgstr ""
+"_Si tienes un parche, dilo._ Un PR que incluye un parche tiene más "
+"posibilidades de recibir atención que uno que no lo tiene. Por favor, "
+"establece la Keyword `patch` en Bugzilla."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:137
+msgid ""
+"_If you are a maintainer, say so._ If you are maintaining a part of the "
+"source code (for instance, an existing port), you definitely should set the "
+"\"Class\" of your PR to `maintainer-update`. This way any committer that "
+"handles your PR will not have to check."
+msgstr ""
+"_Si eres un mantenedor, dilo._ Si mantienes una parte del código fuente (por "
+"ejemplo, un port), entonces deberías establecer el \"Class\" de tu PR a "
+"`maintainer-update`. De este modo cualquier committer que se asigne tu PR no "
+"tendrá que comprobarlo."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:138
+msgid ""
+"_Be specific._ The more information you supply about what problem you are "
+"having, the better your chance of getting a response."
+msgstr ""
+"_Sé específico._ Cuanta más información proporciones acerca del problema que "
+"tienes, mayores serán las posibilidades de obtener una respuesta."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:140
+msgid ""
+"Include the version of FreeBSD you are running (there is a place to put "
+"that, see below) and on which architecture. You should include whether you "
+"are running from a release (e.g., from a CD-ROM or download), or from a "
+"system maintained by Git (and, if so, what hash and branch you are at). If "
+"you are tracking the FreeBSD-CURRENT branch, that is the very first thing "
+"someone will ask, because fixes (especially for high-profile problems) tend "
+"to get committed very quickly, and FreeBSD-CURRENT users are expected to "
+"keep up."
+msgstr ""
+"Incluye la versión de FreeBSD que estás ejecutando (existe un lugar donde "
+"escribir esta información, lee a continuación) y en qué arquitectura. Debes "
+"incluir si se está ejecutando desde una release (por ejemplo, desde un CD-"
+"ROM o descarga), o si es desde un sistema mantenido por Git (y, si es así, "
+"en qué hash y rama te encuentras). Si estás usando la rama FreeBSD-CURRENT, "
+"esa es la primera pregunta que te harán, porque las correcciones ("
+"especialmente para problemas de alto nivel) tienden a solucionarse muy "
+"rápidamente, y se espera que los usuarios de FreeBSD-CURRENT se mantengan al "
+"día."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:141
+msgid ""
+"Include which global options you have specified in your [.filename]#make."
+"conf#, [.filename]#src.conf#, and [.filename]#src-env.conf#. Given the "
+"infinite number of options, not every combination may be fully supported."
+msgstr ""
+"Incluye qué opciones globales has especificado en tus ficheros [."
+"filename]#make.conf#, [.filename]#src.conf#, y [.filename]#src-env.conf#. "
+"Dado el número infinito de opciones, no todas las combinaciones podrían ser "
+"totalmente compatibles."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:142
+msgid ""
+"If the problem can be reproduced easily, include information that will help "
+"a developer to reproduce it themselves. If a problem can be demonstrated "
+"with specific input then include an example of that input if possible, and "
+"include both the actual and the expected output. If this data is large or "
+"cannot be made public, then do try to create a minimal file that exhibits "
+"the same issue and that can be included within the PR."
+msgstr ""
+"Si el problema se puede reproducir fácilmente, incluye información que ayude "
+"al desarrollador a reproducirlo por sí mismo. Si se puede hacer una "
+"demostración con una entrada específica, incluye un ejemplo con esa entrada, "
+"si es posible, e incluye la salida real y la esperada. Si la información es "
+"grande o no se puede hacer pública, intenta crear un archivo con lo mínimo "
+"que muestre el mismo problema y que pueda incluirse en el PR."
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:143
+msgid ""
+"If this is a kernel problem, then be prepared to supply the following "
+"information. (You do not have to include these by default, which only tends "
+"to fill up the database, but you should include excerpts that you think "
+"might be relevant):"
+msgstr ""
+"Si se trata de un problema del kernel, prepárate para proporcionar la "
+"siguiente información. (No es necesario incluir esta información por "
+"defecto, puesto que lo único que produce es un crecimiento desmesurado de la "
+"base de datos, pero sí puede merecer la pena incluir extractos que "
+"consideres importantes):"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:145
+msgid ""
+"your kernel configuration (including which hardware devices you have "
+"installed)"
+msgstr ""
+"la configuración del kernel (incluidos los dispositivos de hardware que has "
+"instalado)"
+
+#. type: Plain text
+#: documentation/content/en/articles/problem-reports/_index.adoc:146
+msgid ""
+"whether or not you have debugging options enabled (such as `WITNESS`), and "
*** 806 LINES SKIPPED ***