|
|
|
|
|
El objetivo principal de este manual es servir como único punto de acceso a toda la documentación referente al Live Systems Project y en particular al sofware que el proyecto crea para Debian 9.0 "stretch". 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 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 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.
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, desde el principio y terminando en la sección Términos. Después, saltar hasta los tres tutoriales que están al principio de la sección Ejemplos pensados para aprender a configurar y construir imágenes de forma básica. Se deberá leer primero Uso de los ejemplos, seguido de Tutorial 1: Una imagen predeterminada y Tutorial 2: Una utilidad de navegador web, para finalizar con Tutorial 3: Una imagen personalizada. 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, y de una manera más somera el capítulo La creación de una imagen netboot, para acabar con la lectura de Descripción general de la personalización 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.
Lista de autores (en orden alfabético):
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 para obtener información detallada sobre cómo obtener la clave pública y hacer buenos commits.
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:
# apt-get install make po4a ruby ruby-nokogiri sisu-complete
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:
$ make build
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.
$ make build PROOF=1
Cuando se revisa alguna de las traducciones, es posible construir sólo un idioma ejecutando, por ejemplo:
$ make build LANGUAGES=de
Es posible generar el documento por formato:
$ make build FORMATS=pdf
O combinar ambos, por ejemplo:
$ make build LANGUAGES=de FORMATS=html
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 para más detalles.
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:
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.
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.