Switch branches/tags
Nothing to show
Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
..
Failed to load latest commit information.
src/img
README.md

README.md

Estructura recomendada para un proyecto editorial

Última actualización: 10 de julio de 2017

Aunque parezca redundante, muchas veces existen problemas en el proceso de elaboración de una publicación simplemente por una falta de organización en los archivos y carpetas. Esta desorganización incluso puede repercutir en la calidad de la edición cuando por accidente de emplean archivos viejos.

En este módulo se verán algunas recomendaciones sobre la organización y estructura de proyectos editoriales, aunque es aconsejable para todo tipo de proyecto.

Por ser recomendaciones, no hay necesidad de seguirlos al pie de la letra…

Módulos relacionados

Índice


1. Uso de un controlador de versiones

El uso de respaldos en un disco duro externo o en la nube no es el control recomendado para la clase de proyectos editoriales debido a la enorme cantidad de archivos involucrados, su constante modificación o el peligro que implica la confusión de «versiones».

Lo recomendado para esta clase de proyectos es el uso de un controlador de versiones para mantener puntos de guardado a lo largo del proyecto sin la necesidad de duplicar archivos.

Si no existe la capacidad para gestionar un controlador de versiones, la segunda posibilidad es el uso de una nube. Con este sistema al menos será posible que todos los involucrados en el proyecto tengan acceso a la información desde cualquier sitio.

En todo caso, evítese el uso de discos duros externos durante la ejecución del proyecto. Si se desea, únicamente déjese esta clase de respaldo cuando el proyecto haya concluido.

¿Qué es un controlador de versiones? Véanse los elementos 8 y 9 de «Edición cíclica y edición ramificada».

2. Todo en un mismo lugar

En lugar de tener la infomación en diversas carpetas, lo aconsejable es tener una carpeta específica para cada proyecto o conjunto de proyectos similares, como pueden ser publicaciones de una misma colección.

Si existe el caso de que se descargó software para el quehacer editorial, también se aconseja que se ponga en una carpeta separada de las publicaciones.

De esta manera de tendrá una carpeta para el proyecto o su conjunto, y una más para el software.

3. No utilizar espacios

Aunque el uso de espacios en un uso ordinario en los nombres de archivos y carpetas no genera problemas, en ciertas circunstancias específicas puede provocar fallos, más si la gran parte de la labor técnica está siendo automatizada.

Por este motivo, no se recomienda usar espacios en los nombres de archivos o carpetas. Por legibilidad, lo acosejable es sustituir los espacios por guiones o guiones bajos. Por ejemplo:

  • Desaconsejable:
    • Nombre de un archivo.txt
    • Nombredeunarchivo.txt
  • Recomendable:
    • nombre-de-un-archivo.txt
    • nombre_de_un_archivo.txt

4. No usar tildes o mayúsculas

Aunque parezca sorprendente, aún mucho software elaborado en el mundo anglófono presenta problemas de codificación al momento de usar tildes. Por internacionalización (¿anglonización?) se desaconseja el uso de tildes para evitar posibles problemas.

Otra recomendación, que es más por un criterio estético, es evitar el uso de mayúsculas y solo usar minúsculas. Entonces:

  • Desaconsejable:
    • AlgúnArchivo.txt
    • Algún archivo.txt
  • Recomendable:
    • algun-archivo.txt
    • algun_archivo.txt

5. Una carpeta para cada formato

Partiendo del supuesto por el cual en un proyecto editorial se generarán varios formatos de la misma obra, lo recomendable es crear una carpeta en el proyecto por cada tipo de formato.

Es decir, suponiendo que en un proyecto se tendrán archivos madre, EPUB y PDF, la estructura general sería:

proyecto
├── archivos-madre
├── epub
├── pdf
└── recursos

¿Qué es un «archivo madre»? Véase el módulo «Metodologías para la edición digital estándar».

6. Una carpeta para los recursos

En un proyecto editorial se tienen dos tipos de archivos según su origen:

  1. Archivos externos y necesarios para empezar una publicación. Por ejemplo, el texto original, las imágenes dadas por el autor, trámites de ISBN, etcétera.
  2. Archivos creados durante la vida del proyecto. Por ejemplo, los forros, el texto editado, gráficas, etcétera.

Cuando estos recursos se necesitan para todos los formatos, lo recomendable es tenerlos en una carpeta independiente. Ejemplo:

proyecto
├── archivos-madre
├── epub
├── pdf
└── recursos

El directorio recursos puede ser más específico y dividir los recursos según los tipos mencionados con anterioridad. Ejemplo:

proyecto
├── archivos-madre
├── epub
├── pdf
└── recursos
    ├── externos
    └── internos

7. Carpetas para cada tipo de archivo

Además de un orden según el formato final y los recursos, también es aconsejable que en cada uno de esos directorios se creen carpetas según el tipo de archivos que contiene. Las carpetas pueden ser para aglutinar imágenes, textos, multimedia u otro tipo de campo semántico que se considere pertinente. Por ejemplo:

proyecto
├── archivos-madre
│   ├── img
│   └── md
├── epub
│   ├── audios
│   ├── img
│   └── xhtml
├── pdf
│   ├── fuentes
│   └── img
└── recursos
    ├── externos
    │   ├── img
    │   ├── textos
    │   └── administrativo
    └── internos
        ├── audios
        ├── img
        └── textos

8. Eliminar archivos innecesarios

La limpieza de un proyecto no solo reside en evitar duplicados de archivos para respaldo y en su lugar usar un controlador de versiones. También es aconsejable eliminar todo archivo que ya no será necesario en el futuro.

Ejemplo de estos archivos pueden ser imágenes o textos que han sido editados, archivos que no se requieren para el proyecto, etcétera.

Ojo: que un archivo no sea necesario en el estado actual del proyecto no implica que será innecesario en el futuro. En el caso particular de imágenes en alta resolución o archivos editables (p. ej. imágenes ps de donde se obtuvieron los jpg), considérese su pertinencia a futuro antes de eliminarlos.

Nota: en un controlador de versiones es posible regresar y recuperar archivos eliminados.

9. Uniformidad en los nombres y en la estructura

La última recomendación es tratar de mantener la misma estructura en cada uno de los proyectos. Así se obtienen las siguientes ventajas:

  1. Facilidad de comprensión para otras personas.
  2. Mayor control en los archivos de un proyecto.
  3. Posibilidad de implementar procesos de automatización.

Para los nombres también es recomendable cierta uniformidad cuando se tratan de archivos seriados. Un caso muy común es el nombre de imágenes:

  • Desaconsejable:
    • Alguna fotografía de una casa.jpg
    • Esta es una gráfica sobre algo.jpg
    • Y una imagen más.jpg
  • Recomendable:
    • img01.jpg
    • img02.jpg
    • img03.jpg

Otro caso también es cuando se divide una obra:

  • Desaconsejable:
    • Capítulo 1.xhtml
    • Capítulo 2.xhtml
    • Conclusión.xhtml
    • Introducción.xhtml
  • Recomendable:
    • 001-introduccion.xhtml
    • 002-capitulo01.xhtml
    • 003-capitulo02.xhtml
    • 004-conclusion.xhtml

Recursos

  1. «Edición cíclica y edición ramificada».