1 files changed, 0 insertions, 299 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
deleted file mode 100644
index c4aabf2..0000000
--- a/markup/pod/live-manual/media/text/es/about_manual.ssi
+++ /dev/null
@@ -1,299 +0,0 @@
-: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.