1 files changed, 299 insertions, 0 deletions
diff --git a/markup/pod/live-manual/media/text/es/about_manual.ssi b/markup/pod/live-manual/media/text/es/about_manual.ssi
new file mode 100644
index 0000000..c4aabf2
--- /dev/null
+++ b/markup/pod/live-manual/media/text/es/about_manual.ssi
@@ -0,0 +1,299 @@
+:B~ Acerca de este manual
+
+1~about-manual Acerca de este manual
+
+El objetivo principal de este manual es servir como único punto de acceso a
+toda la documentación referente al ${project} y en particular al sofware que
+el proyecto crea para Debian 9.0 "${stable}". Se puede encontrar siempre una
+versión actualizada en http://live-systems.org/
+
+live-manual está principalmente enfocado a ayudar en la creación de un
+sistema en vivo y no está dirigido al usuario final de estos sistemas. Un
+usuario final puede encontrar información útil en las siguentes secciones:
+{Conceptos básicos}#the-basics que cubre la descarga de imágenes
+prefabricadas y la preparación de imágenes para arrancar un sistema desde un
+medio de almacenamiento o desde una red local, ya sea utilizando el
+constructor web o ejecutando live-build directamente en el
+sistema. {Personalización del comportamiento en tiempo de
+ejecución}#customizing-run-time-behaviours que describe algunas de las
+opciones que pueden especificarse en el indicador de arranque, como pueden
+ser la selección de la distribución del teclado, las variantes locales o la
+persistencia.
+
+Algunos de los comandos mencionados en el texto deben ser ejecutados con
+privilegios de superusuario, que pueden ser obtenidos accediendo a la cuenta
+de root mediante la orden #{su}# o mediante la orden #{sudo}#. Para
+distinguir las ordenes que deben ser ejecutadas como usuario no privilegiado
+de las que si requieren privilegios de superusuario se ha prefijado con
+#{$}# las primeras y con #{#}# las segundas. Estos símbolos no son parte de
+la orden.
+
+2~ Para el impaciente.
+
+Aunque se cree que todo lo descrito en este manual es importante para la
+mayoría de los usuarios, es cierto que hay mucho material a interiorizar y
+que los usuarios desean experimentar con las herramientas de forma rápida y
+satisfactoria antes de entrar en detalles. Por lo tanto, se sugiere leer
+siguiendo el siguiente orden.
+
+Primero, leer el capítulo {Acerca de este manual}#about-manual, desde el
+principio y terminando en la sección {Términos}#terms. Después, saltar hasta
+los tres tutoriales que están al principio de la sección {Ejemplos}#examples
+pensados para aprender a configurar y construir imágenes de forma básica. Se
+deberá leer primero {Uso de los ejemplos}#using-the-examples, seguido de
+{Tutorial 1: Una imagen predeterminada}#tutorial-1 y {Tutorial 2: Una
+utilidad de navegador web}#tutorial-2, para finalizar con {Tutorial 3: Una
+imagen personalizada}#tutorial-3. Al final de estos tutoriales, el lector
+tendrá una visión de lo que se puede hacer con los sistemas en vivo.
+
+Se anima a profundizar en el estudio del manual con la lectura detenida del
+siguiente capítulo: {Conceptos básicos}#the-basics, y de una manera más
+somera el capítulo {La creación de una imagen
+netboot}#building-netboot-image, para acabar con la lectura de {Descripción
+general de la personalización}#customization-overview y los capítulos que le
+siguen. Se espera que, en este punto, el lector esté lo suficientemente
+motivado con lo que se puede hacer con los sistemas en vivo para leer el
+resto del manual, de principio a fin.
+
+2~terms Términos
+
+_* *{Sistema en vivo}*: Se entiende por sistema en vivo aquel sistema
+operativo que se puede arrancar sin instalación previa en el disco duro. Un
+sistema en vivo no altera ningún sistema operativo previamente instalado ni
+ningún fichero existente en el disco duro de la máquina a menos que se le
+instruya para hacerlo. Los sistemas en vivo son arrancados típicamente desde
+medios extraíbles como CDs, DVDs o llaves USB. Algunos pueden también
+arrancar desde la red local (utilizando imágenes tipo netboot, ver {Creación
+de una imagen de arranque en red}#building-netboot-image), o incluso desde
+internet utilizando el parámetro de arranque #{fetch=URL}#, ver {Arrancar
+desde internet}#webbooting).
+
+_* *{Medio en vivo}*: A diferencia de sistema en vivo, el medio en vivo se
+refiere al CD, DVD o memoria USB donde se copia el fichero binario producido
+por live-build y utilizado para arrancar el sistema en vivo. Más
+ampliamente, el término también se refiere a cualquier lugar en el que
+reside el fichero binario a los efectos de iniciar el sistema en vivo, tales
+como la ubicación de los ficheros de arranque de red.
+
+_* *{${project}}*: Es un proyecto que mantiene, entre otros, los paquetes
+live-boot, live-build, live-config, live-tools y live-manual.
+
+_* *{Sistema huésped}*: Es el conjunto de herramientas y equipo utilizado
+para crear el sistema en vivo.
+
+_* *{Sistema objetivo}*: Es el conjunto de herramientas y equipo donde se
+ejecutará el sistema en vivo.
+
+_* *{live-boot}*: Es una colección de scripts que serán responsables de
+arrancar el sistema en vivo.
+
+_* *{live-build}*: Una colección de scripts utilizados para construir
+sistemas en vivo personalizados.
+
+_* *{live-config}*: Es una colección de scripts utilizados para configurar
+un sistema en vivo durante el proceso de arranque.
+
+_* *{live-tools}*: Una colección de scripts adicionales que se utilizan para
+realizar tareas útiles en un sistema en vivo en ejecución.
+
+_* *{live-manual}*: Este documento forma parte de un paquete llamado
+live-manual.
+
+_* *{Instalador de Debian (Debian Installer o d-i)}*: Es el mecanismo
+oficial de instalación para la distribución Debian.
+
+_* *{Parámetros de arranque}*: Parámetros que son entregados al gestor de
+arranque (bootloader) para modificar el comportamiento del kernel o del
+conjunto de scripts live-config. Son llamados también Parámetros de kernel u
+Opciones de arranque.
+
+_* *{chroot}*: El programa /{chroot}/, #{chroot(8)}#, permite ejecutar
+diferentes instancias de un entorno GNU/Linux en un solo sistema de manera
+simultánea sin necesidad de reiniciar el sistema.
+
+_* *{Imagen binaria}*: Es un fichero que contiene el sistema en vivo. Su
+nombre puede ser, por ejemplo, live-image-i386.hybrid.iso o
+live-image-i386.img dependiendo de su formato.
+
+_* *{Distribución objetivo}*: Es la versión de la distribución Debian en la
+cual estará basado el sistema en vivo que puede diferir de la versión de la
+distribución en el sistema huésped.
+
+_* *{stable/testing/unstable}*: La distribución *{stable}*, actualmente
+llamada ${stable}, contiene la última distribución Debian publicada
+oficialmente. La distribución *{testing}*, temporalmente llamada ${testing},
+está en la rampa de salida para ser la próxima distribución *{stable}*. La
+principal ventaja de utilizar esta distribución es que tiene versiones de
+programas más recientes si se compara con la versión *{stable}*. La
+distribución *{unstable}*, permanentemente llamada sid, es dónde se realiza
+el desarrollo de Debian. Generalmente esta distribución es usada por los
+desarrolladores y aquellos que les gusta vivir al filo de lo imposible. A lo
+largo del manual, se usan sus nombres en clave, como por ejemplo ${testing}
+o sid, ya que es lo que las mismas herramientas reconocen. 
+
+2~ Autores
+
+Lista de autores (en orden alfabético):
+
+_* Ben Armstrong
+
+_* Brendan Sleight
+
+_* Carlos Zuferri
+
+_* Chris Lamb
+
+_* Daniel Baumann
+
+_* Franklin Piat
+
+_* Jonas Stein
+
+_* Kai Hendry
+
+_* Marco Amadori
+
+_* Mathieu Geli
+
+_* Matthias Kirschner
+
+_* Richard Nelson
+
+_* Trent W. Buck
+
+2~how-to-contribute Cómo contribuir a este documento
+
+Este manual se ha creado como un proyecto comunitario y cualquier propuesta
+para su mejora u otras contribuciones son siempre bienvenidas. Ver la
+sección {Contribuir al proyecto}#contributing-to-project para obtener
+información detallada sobre cómo obtener la clave pública y hacer buenos
+commits.
+
+3~applying-changes Aplicar cambios
+
+Para realizar cambios en el manual en Inglés se debe editar los ficheros
+adecuados en #{manual/en/}# pero antes de enviar una contribución se debería
+realizar una visualización del trabajo realizado. Para ello asegurarse de
+tener instalados los paquetes necesarios para la construcción de live-manual
+ejecutando la siguiente orden:
+
+code{
+
+ # apt-get install make po4a ruby ruby-nokogiri sisu-complete
+
+}code
+
+Se puede realizar la construcción del manual posicionándose en el directorio
+de nivel superior, o sea, en el directorio clonado mediante Git y ejecutando
+la siguiente orden:
+
+code{
+
+ $ make build
+
+}code
+
+Ya que construir el manual completo en todos los idiomas disponibles cuesta
+bastante rato, los autores seguramente estaran interesados en utilizar
+alguno de los siguientes atajos a la hora de revisar la documentación que
+hayan añadido al manual en inglés. Utilizando #{PROOF=1}# se crea
+live-manual en formato html, pero sin los documentos html segmentados, y
+utilizando #{PROOF=2}# se crea live-manual en formato pdf pero sólo en
+retrato A4 y carta. Por este motivo, utilizar cualquiera de las opciones
+#{PROOF=}# puede llegar a ahorrar una cantidad de tiempo considerable, por
+ejemplo.
+
+code{
+
+ $ make build PROOF=1
+
+}code
+
+Cuando se revisa alguna de las traducciones, es posible construir sólo un
+idioma ejecutando, por ejemplo:
+
+code{
+
+ $ make build LANGUAGES=de
+
+}code
+
+Es posible generar el documento por formato:
+
+code{
+
+ $ make build FORMATS=pdf
+
+}code
+
+O combinar ambos, por ejemplo:
+
+code{
+
+ $ make build LANGUAGES=de FORMATS=html
+
+}code
+
+Después de revisar el trabajo y asegurarse de que todo está bien, no
+ejecutar #{make commit}# a menos de que se actualicen las traducciones al
+mismo tiempo, y en ese caso, no mezclar los cambios al manual en inglés con
+las traducciones en el mismo commit, sino en commits separados. Ver la
+sección {Traducción}#translation para más detalles.
+
+3~translation Traducción
+
+Para traducir live-manual, seguir estos pasos, dependiendo de si se está
+comenzando una traducción desde cero o si se continua trabajando en una
+traducción ya comenzada:
+
+_* Empezar una nueva traducción desde cero
+
+_2* Traducir los ficheros *{about_manual.ssi.pot}*,
+*{about_project.ssi.pot}* y *{index.html.in.pot}* de #{manual/pot/}# al
+idioma deseado con cualquier editor (como puede ser /{poedit}/). Enviar los
+ficheros #{.po}# traducidos a la lista de correo para revisar su
+integridad. La comprobación de integridad de live-manual no sólo se asegura
+de que los ficheros #{.po}# estén 100% traducidos sino que también detecta
+posibles errores.
+
+_2* Una vez comprobados, para activar una nueva lengua en el autobuild basta
+con añadir los ficheros traducidos inicialmente a #{manual/po/${LANGUAGE}/}#
+y ejecutar #{make commit}#. Y entonces, editar
+#{manual/_sisu/home/index.html}# añadiendo el nombre de la lengua y su
+nombre en inglés entre paréntesis.
+
+_* Continuar con una traducción ya comenzada
+
+_2* Si el nuevo idioma ya ha sido añadido, se puede continuar la traducción
+de los ficheros .po restantes en #{manual/po/${LANGUAGE}/}# de manera
+aleatoria utilizando el editor preferido (como por ejemplo /{poedit}/).
+
+_2* No se debe olvidar la ejecución del comando #{make commit}# para
+actualizar los manuales traducidos a partir de los ficheros .po. Entonces se
+puede revisar los cambios ejecutando #{make build}# antes de #{git add .}#,
+#{git commit -m "Translating..."}# y #{git push}#. Recordar que como #{make
+build}# puede tardar una cantidad considerable de tiempo, se pueden revisar
+las diferentes lenguas de forma individual como se explica en {Aplicar
+cambios}#applying-changes 
+
+Después de ejecutar #{make commit}# se podrá observar bastante texto en la
+pantalla.  Básicamente son mensajes informativos sobre el estado del proceso
+y también algunas pistas sobre lo que se puede hacer para mejorar
+live-manual. A menos que se vea un error fatal, generalmente se puede
+proceder y enviar la contribución.
+
+live-manual incluye dos utilidades que pueden ser de gran ayuda para los
+traductores a la hora de encontrar mensajes sin traducir y mensajes
+difusos. La primera es "make translate". Esta activa un script que muestra
+en detalle cuántos mensajes sin traducir hay en cada fichero .po. La
+segunda, "make fixfuzzy", sólo actúa sobre los mensajes difusos pero ayuda a
+encontrarlos y corregirlos uno por uno.
+
+Hay que tener en cuenta que aunque estas utilidades pueden ser de gran ayuda
+para traducir en la linea de comandos, se recomienda el uso de una
+herramienta especializada como por ejemplo /{poedit}/. Además, es una buena
+idea leer la documentación de debian sobre localizacion (l10n) y,
+especificamente para live-manual, las {Directrices para los
+traductores}#guidelines-translators.
+
+*{Nota:}* Se puede utilizar #{make clean}# para limpiar el árbol git antes de enviar los cambios. Este paso no es obligatorio, gracias al fichero .gitignore, pero es una buena práctica para evitar enviar ficheros involuntariamente.