| Estudio de las herramientas utilizadas dentro del proyecto de software libre Debian GNU/Linux | ||
|---|---|---|
| Anterior | Siguiente | |
Se va a ver a continuación los detalles del método de publicación escogido por Debian para publicar los contenidos de su servidor de WWW y las distintas particularidades de éste que hacen que su internacionalización por parte de grupos dedicados de traducción sea relativamente sencillo.
WML es una herramienta que permite el diseño de webs corporativos, facilitando la posibilidad de integrar tareas programas y así variar el aspecto de cada una de las páginas en función de variables externas, comprobadas en tiempo de compilación.
Para hacer comprobar la relación de wml con html es conveniente hacer una analogía con la generación de programas en cualquier lenguaje de programación. En aquellos se tiene un código fuente que se compila para obtener un programa final, el ejecutable, con pasos intermedios (que genera el código objeto). Podríamos decir que las páginas html se generan "compilando" el código escrito en wml (y será, por tanto, el código fuente de nuestro servidor). Es necesario observar que que ni el usuario final ni su navegador tratarán con el código wml.
WML se trata, por tanto, de un superconjunto de html junto con un preprocesador y compilador que permitirán:
redefinir etiquetas o definir nuevas etiquetas que se usarán en los documentos fuente.
arreglar automáticamente errores o definiciones mal hechas en el código HTML
introducir programas escritos en otros lenguajes que definan aspectos de la página de forma automática.
WML se utiliza debido a que la definición del WWW Consortium de las hojas de estilo en cascada (CCS Style Sheets) no se encuentra aún correctamente implementada en los navegadores, existiendo diferencias que impiden su perfecto aprovechamiento para todas las tareas necesarias . Asimismo, aunque se podrían usar hojas de estilo, el uso de WML supone una ventaja al poder automatizar una serie de tareas (como la generación de algunos menús) que precisan un procesamiento previo de las páginas que puede no ser conveniente dejar del lado del cliente.
Hay que destacar que con WML se implementan cuatro elementos claves del servidor:
El estilo. Que identifica cómo se representan los textos, los hiper-enlaces, etc... : colores, separación entre líneas, tipo de letra...
La plantilla general. Que identifica el aspecto de todas y cada una de las páginas del servidor, en lo que respecta a elementos generales (barras de botones, pies de página, etc..).
La programación de las páginas. Que permite establecer contenidos dinámicos y dependientes de alguna situación particular.
La internacionalización de las páginas. Ya que WML permite definir etiquetas que dependan de opciones de compilación. En función del parámetro entregado a WML a la hora de compilar se introducirá un texto u otro.
De estos elementos, sólo los dos primeros podrían ser implementado utilizando hojas de estilo (CSS) ni otras alternativas, como podrían ser la utilización de XML.
Esta introducción de zonas de código (generalmente escritas en Perl que se ejecutan cada vez que se compilan las páginas, permite que el resultado pueda depender del idioma objetivo del documento, la fecha, la existencia de otros ficheros, la información en bases de datos, etc.
En el diseño de todo servidor se desea tener una presentación homogénea de los contenidos. Pero puede ser difícil lograrlo si la definición de estructura y aspecto se encuentra en cada uno de los documentos de forma que si se desea cambiar el aspecto general es necesario cambiar todos los documentos uno por uno, existiendo la posibilidad de que queden documentos sin cambiar y se pierda, por tanto, la uniformidad.
Se tiende, por tanto, a un esquema centralizado en el que exista una sola definición global, pudiéndose cambiar esta y así cambiar el aspecto general de todos los documentos. De esta manera es posible cambiar la "metáfora" sin cambiar el contenido. Uno de los objetivos en la definición del aspecto global es que el documento (la información a mostrar) es sólo una parte del aspecto. Relacionando la plantilla con la información se obtiene el documento final.
Aunque es posible llevar esto a cabo con herramientas programadas "ad hoc" para un servidor en concreto, WML ofrece esta posibilidad de manera inmediata, sin tener que recurrir a programas hechos a medida.
Una de las desventajas, sin embargo, del uso de plantillas en WML es que para ver el aspecto final es necesario compilar la página. Es un problema similar a los lenguajes de definición de marcas como LaTeX, la solución a esto es incrementar la velocidad de procesamiento de forma que este tiempo se haga despreciable.
Como ejemplo de una plantilla, se incluye a continuación la plantilla básica del servidor.
Como se puede ver, dentro de la plantilla se definen componentes variables, para los que se utilizan variables, e incluso componentes que dependen de las variables en sí (como se ve en la Descripción). La llamada a otros componentes de la plantilla, como la barra de navegación, se hacen incluyendo nuevas plantillas wml (con la directiva #use) y el cuerpo del documento introducido a continuación. Un documento que haga uso de esta plantilla podría ser el siguiente:
La plantilla elegida se indica con la primera línea del documento (a la que se la pueden pasar parámetros, como por ejemplo el título) y la información del propio documento (a partir del tag <H2>) es la que se introduce en la zona definida como {#body#} en la plantilla. El resultado de la ejecución de wml sobre este documento es una página HTML con el aspecto indicado en la plantilla y con el contenido del documento en sí.
WML también permite la definición de tags dentro de los documentos (generalmente estas definiciones se ubicarán en las plantillas) de forma que éstas se expanden a los valores definidos en la inclusión de documentos. Así, es posible definir, por ejemplo, el tag <aviso> a una representación HTML apropiada para esta situación, como podría ser "<H1>¡AVISO!</H1>". El uso de estos elementos simplifica en gran medida la producción de información, al tiempo que permite independizar, aún más, el contenido de la representación de éste ya que es posible definir elementos con contenido semántico que luego, en compilación, sean sustituidos por sus correspondientes elementos visuales.
Dentro del servidor de Debian, la definición de tags es amplia y se realiza en las propias plantillas. Esta definición permite implementar fácilmente características como los pies de página (incluyendo la fecha de modificación de documento), los elementos de la barra de menús, etc.
Pero además, estas definiciones, junto con el mecanismo de "rodajas" permiten establecer textos que se repiten con frecuencia en el servidor de forma que no sea necesario traducirlos en cada uno de los documentos, sino que se traducen directamente en las plantillas (una sola vez) y se incluyen en los documentos directamente. El mecanismo de rodajas de WML permite definir múltiples representaciones para un mismo elemento y, en función de las opciones de compilación, seleccionar una u otra para la representación final. Como se puede ver a continuación, la definición de rodajas es tremendamente sencilla y ahorra trabajo de traducción en zonas que se repiten en todo el servidor (como las barras de menús, y las cabeceras o pies de página).
Una de las grandes ventajas de WML es la introducción de código embebido dentro de las páginas. En principio, WML tiene capacidad de ejecutar, directamente, scripts de código ePerl (Perl embebido) incluidos dentro de las páginas, lo que permite que determinada información se implemente de forma dinámica. Esta información puede ser desde la fecha actual para su inclusión en los documentos, hasta información de noticias más actuales (seleccionadas de entre las noticias disponibles), elementos extraídos de otras bases de datos o información sobre el estado de las traducciones.
Como ejemplos podemos ver, por un lado, la generación de noticias, cuya definición en WML es la que sigue:
Este fragmento de código, llamado desde otra página WML utilizando la rutina news_index(año) recorrerá el directorio correspondiente al año indicado recogiendo todos los ficheros wml presentes en él y extrayendo de éstos la información de título y fecha, con esta información se generará un índice de elementos enlazados directamente a las noticias con su título y fecha.
Otra aplicación interesante de la utilización de código es el aprovechamiento de la existencia de un control de versiones en CVS del servidor para determinar si los documentos traducidos están, o no, actualizados frente a los documentos originales. Y es la que se muestra a continuación:
<perl>
sub check_translation {
my ($translation, $file, $original, $mindelta, $maxdelta) = @_;
$max_versions = $maxdelta || 5;
$min_versions = $mindelta || 2;
$debug = 0;
$original_lang = $original ? $langs{$original} : "en";
$link = $file;
$link =~ s/\.wml$//;
$link .= ".$original_lang.html";
$original_dir = $original ? "$original" : "english";
@full_directory_name = split '/', $WML_SRC_DIRNAME;
$dir = pop @full_directory_name;
while ($dir) {
push @relative_dir, $dir;
$dir = pop @full_directory_name;
}
for (; $level > 0; $level--) { $parents .= "../"; }
pop @relative_dir;
@relative_dir = reverse @relative_dir;
$relative_dir = join '/', @relative_dir;
open (CVS_ENTRY,"<$parents/$original_dir/$relative_dir/CVS/Entries")
or die "Couldn't open $parents/$original_dir/$relative_dir/CVS/Entries: $!\n";
while (<CVS_ENTRY>) {
($version) = $_ =~ m,/\Q$file\E/([\d\.]*),;
last if $version;
}
close CVS_ENTRY;
if ($version ne "")
{
print ${file} . "'s original CVS revision is: $version\n"
if ($debug >= 1);
@version_numbers = split /\./,$version;
$major_number = @version_numbers[0];
$last_number = pop @version_numbers;
die "Invalid CVS revision for $file: $version\n"
unless ($major_number =~ /\d+/ and $last_number =~ /\d+/);
@translation_numbers = split /\./,$translation;
$major_translated_number = @translation_numbers[0];
$last_translated_number = pop @translation_numbers;
die "Invalid translation revision for $file: $translation\n"
unless ($major_translated_number =~ /\d+/ and $last_translated_number =~ /\d+/);
}
print "Comparing original $version to translation version $translation\n" if ($debug >= 1);
if ($version eq "")
{
print qq(<originalgone>)
}
elsif ( $major_number != $major_translated_number ) {
print qq(<translationoutofdate>)
}
elsif ( $last_number - $last_translated_number >= $max_versions ) {
print qq(<translationoutofdate>)
}
elsif ( $last_number - $last_translated_number >= $min_versions ) {
}
}
</perl>
<: check_translation ("$(translation)","$WML_SRC_FILENAME",
"$(original)","$(mindelta)","$(maxdelta)") :>
Un documento que desee hacer este chequeo sólo tiene que añadir en su cabecera #use wml::debian::translation-check translation="X.xx". Esta llamada incluirá la plantilla indicada que ejecutará la subrutina check_translation. Dicha subrutina busca la ubicación del documento original (generalmente éste estará escrito en inglés) y, una vez encontrado, consulta los ficheros de control del sistema de control de versiones para ver la versión actual de dicho documento. La versión encontrada es contrastada con la versión indicada por el traductor, que corresponde con la que éste tradujo. Así, es posible determinar si la traducción está desfasada (e incluso el número de revisiones de diferencia) lo que permite incluir un aviso para el lector del documento indicando esta circunstancia. Dicho aviso (no mostrado pero implementado con "tags") tendrá una referencia directa al documento original cuando la traducción esté demasiado desactualizado (este "demasiado" es controlable por el traductor ya que corresponde a un umbral fijado de la diferencia en revisiones entre uno y otro documento).
Para hacer posible la modificación por parte de un número elevado de desarrolladores del servidor de Web y de traductores, toda la jerarquía de las fuentes del servidor están publicadas bajo un sistema de control de versiones. Además de las ventajas de la utilización de este tipo de sistemas, ya mencionadas previamente en la la sección de nombre Servicios de control de versiones, en el caso de publicación multilingüe se añade la capacidad de gestionar las diferencias entre versiones del documento original y de sus sucesivas traducciones.
Como ya se ha indicado previamente, estas verificaciones se pueden hacer de forma que el documento final salga modificado en función de su situación, pero, en cualquier caso, también se han desarrollado herramientas para poder estudiar el estado general de las traducciones.
La base de todas estas modificaciones es el número de revisión que CVS asigna automáticamente a todo fichero que se entrega, con modificaciones, al servidor de control de versiones. De esta forma, cuando un usuario modifica el documento A, que está en la versión 1.1, el servidor de CVS, al recibirlo, le modifica la versión a la 1.2. Así, si los traductores "marcan" sus documentos con la versión del documento original utilizada para la traducción (que se puede obtener fácilmente a partir de la copia local obtenida del servidor de CVS) es posible trazar la evolución de las traducciones frente al documento original de una forma automática.
En cualquier caso, la distribución mediante CVS ha permitido que los distintos equipos de trabajo, de forma segura, asignen distintas zonas del servidor a distintos traductores que se responsabilizan de mantener las páginas actualizadas. Igualmente, el sistema de control de versiones permite recuperar modificaciones mal realizadas sobre los documentos originales y las traducciones. Pero, más importante, el sistema de control de versiones permite obtener las diferenciase entre documentos que han sido modificados. Esta posibilidad es muy importante para la adecuada actualización de traducciones ya que un traductor puede, de forma inmediata, obtener las diferencias entre la versión X (la que tradujo) y la versión Y (la actual) de un documento determinado. Esto facilita en gran medida el trabajo de actualización ya que los puntos concretos donde se debe efectuar actualizaciones están muy acotados, y el traductor se puede concentrar en éstos (y olvidarse del resto del documento) a la hora de actualizar.
La compilación del servidor se realiza una vez al día sobre los contenidos actualizados de una copia local recogida del servidor de versiones (de forma que se está seguro de utilizar la última versión disponible). Para facilitar las tareas de compilación, se utiliza una estructura de ficheros Makefile y se utiliza la herramienta de GNU make para compilar toda la estructura de directorios. Make es una herramienta ampliamente utilizada en entornos de programación para facilitar la compilación, linkado y creación de ejecutables a partir de código fuente. El programador, para hacer uso de esta herramienta, ha de definir una serie de reglas que encaminen al programa a la consecución de objetivos (como podría ser el compilar un programa) con la ventaja de que es posible siempre partir de un instante inicial o de un punto intermedio. No es necesario repetir operaciones si los cambios realizados no obligan a repetirlas. La aplicación a la publicación de contenidos es inmediata ya que el objetivo es la generación de un objeto final (una página HTML) a partir un código inicial (fichero WML) y unas plantillas (incluidas automáticamente por el preprocesador de WML).
Para evitar que la definición de los objetivos esté dispersa por todo el árbol de directorios que se va a publicar. En Debian se utiliza un sólo fichero (Makefile.common) que concentra todos los objetivos y métodos de instalación. Así, los objetivos comunes: all, install, clean y cleandest están agrupados, así como las reglas para generar los ficheros a partir de las fuentes. Los objetivos hacen las siguientes tareas:
fuerza la compilación de todos los ficheros, ya que para que se cumpla tienen que existir todos los ficheros html de los que depende. Esto dispara otras reglas, como por ejemplo local que en principio es una regla vacía en todos los ficheros, pero se mantiene para poder incorporar algún procesamiento específico en algún directorio que lo necesite. La regla también tiene efecto recursivo, ejecutándose en todos los subdirectorios que existan.
copia todos los ficheros procesados a su destino, creando, si fuera necesario, el directorio sobre el que se van a copiar.
borra todos los ficheros que hayan sido procesados. De esta forma se puede obtener un directorio de desarrollo completamente limpio, sin ficheros intermedios resultados de la compilación
borra todos los ficheros instalados en el directorio destino. Dejando el directorio como si no se hubiera instalado los ficheros procesados.
Como se puede observar a continuación en el fichero Makefile.common, todas las reglas de generación de ficheros HTML y de copia de ficheros gráficos (eps, png, gif, jpg...) se encuentran unificadas en un sólo fichero que será incluido por los demás. De igual forma, la localización del directorio destino (donde se copiaran todos los ficheros compilados y ficheros gráficos) viene aquí predefinida. El directorio de instalación es siempre el mismo, independientemente del lenguaje, dado que será la configuración del servidor de web (Apache) y la del navegador la que determine el fichero en cuestión a servir en función del idioma del usuario.
# Nothing in here should require any modification. If you feel you need to
# modify something first send mail to debian-www explaining why.
CUR_YEAR := $(shell date +%Y)
RELHTMLBASE := ../../debian.org
ENGLISHSRCDIR := $(WMLBASE)/../english
TEMPLDIR := $(ENGLISHSRCDIR)/template/debian
ENGLISHDIR := $(ENGLISHSRCDIR)
# ^ just an alias ^
HTMLDIR = $(WMLBASE)/$(RELHTMLBASE)/$(CUR_DIR)
LANGUAGECAP = $(shell echo $(LANGUAGE) | tr "a-z" "A-Z")
WMLOPTIONS := -q -D CUR_YEAR=$(CUR_YEAR)
WMLOUTFILE = $(@F)
WMLPROLOG :=
WMLEPILOG :=
WML = wml $(WMLOPTIONS) \
-o UNDEFu$(LANGUAGECAP):$(WMLOUTFILE)@g+w \
$(WMLPROLOG) $(WMLEPILOG)
WMLFILES = $(wildcard *.wml)
ifndef SUBLANG
HTMLFILES = $(patsubst %.wml,%.$(LANGUAGE).html,$(WMLFILES))
HTMLDESTFILES = $(patsubst %.wml,\
$(HTMLDIR)/%.$(LANGUAGE).html,$(WMLFILES))
else
HTMLFILES = $(sort $(foreach i,$(SUBLANG),\
$(patsubst %.wml,%.$(LANGUAGE)-$(i).html,$(WMLFILES))))
HTMLDESTFILES = $(sort $(foreach i,$(SUBLANG),\
$(patsubst %.wml,$(HTMLDIR)/%.$(LANGUAGE)-$(i).html,\
$(WMLFILES))))
endif
JPGSOURCE := $(wildcard *.jpg)
JPGDESTFILES := $(patsubst %,$(HTMLDIR)/%,$(JPGSOURCE))
GIFSOURCE := $(wildcard *.gif)
GIFDESTFILES := $(patsubst %,$(HTMLDIR)/%,$(GIFSOURCE))
PNGSOURCE := $(wildcard *.png)
PNGDESTFILES := $(patsubst %,$(HTMLDIR)/%,$(PNGSOURCE))
PSSOURCE := $(wildcard *.ps.gz)
PSDESTFILES := $(patsubst %,$(HTMLDIR)/%,$(PSSOURCE))
EPSSOURCE := $(wildcard *.eps)
EPSDESTFILES := $(patsubst %,$(HTMLDIR)/%,$(EPSSOURCE))
PDFSOURCE := $(wildcard *.pdf)
PDFDESTFILES := $(patsubst %,$(HTMLDIR)/%,$(PDFSOURCE))
FIGSOURCE := $(wildcard *.fig)
FIGDESTFILES := $(patsubst %,$(HTMLDIR)/%,$(FIGSOURCE))
XCFSOURCE := $(wildcard *.xcf.gz)
XCFDESTFILES := $(patsubst %,$(HTMLDIR)/%,$(XCFSOURCE))
CSSSOURCE := $(wildcard *.css)
CSSDESTFILES := $(patsubst %,$(HTMLDIR)/%,$(CSSSOURCE))
IMGFILES := $(JPGSOURCE) $(GIFSOURCE) $(PNGSOURCE) $(PSSOURCE) \
$(EPSSOURCE) $(PDFSOURCE) $(FIGSOURCE) $(XCFSOURCE) $(CSSSOURCE)
IMGDESTFILES := $(JPGDESTFILES) $(GIFDESTFILES) $(PNGDESTFILES) \
$(PSDESTFILES) $(EPSDESTFILES) $(PDFDESTFILES) $(FIGDESTFILES) \
$(XCFDESTFILES) $(CSSDESTFILES)
existing-SUBS := $(shell for dir in $(wildcard $(SUBS)) ''; \
do test -d $$dir && echo $$dir; done)
existing-SUBS-install := $(addsuffix -install,$(existing-SUBS))
existing-SUBS-clean := $(addsuffix -clean,$(existing-SUBS))
existing-SUBS-cleandest := $(addsuffix -cleandest,$(existing-SUBS))
# rules
all:: $(HTMLFILES) $(existing-SUBS)
$(existing-SUBS):
-$(MAKE) -C $@
install::
test -d $(HTMLDIR) || mkdir -m g+w -p $(HTMLDIR)
install:: $(HTMLDESTFILES) $(IMGDESTFILES) $(existing-SUBS-install)
$(existing-SUBS-install):
-$(MAKE) -C $(subst -install,,$@) install
clean::
rm -f *.$(LANGUAGE).html
clean:: $(existing-SUBS-clean)
$(existing-SUBS-clean):
-$(MAKE) -C $(subst -clean,,$@) clean
cleandest::
rm -f $(HTMLDIR)/*.$(LANGUAGE).html
cleandest:: $(existing-SUBS-cleandest)
$(existing-SUBS-cleandest):
-$(MAKE) -C $(subst -cleandest,,$@) cleandest
# subdirectories of News, events and security dirs each have
# their own generic wml file deps
ifneq "$(findstring /News/,$(CURDIR))" ""
NOGENERICDEP := true
endif
ifneq "$(findstring /events/,$(CURDIR))" ""
NOGENERICDEP := true
endif
ifneq "$(findstring /security/,$(CURDIR))" ""
NOGENERICDEP := true
endif
# the rule for every wml file
ifndef NOGENERICDEP
%.$(LANGUAGE).html : %.wml $(WMLBASE)/../.wmlrc $(WMLBASE)/.wmlrc \
$(TEMPLDIR)/template.wml $(TEMPLDIR)/languages.wml $(HTMLDEP)
$(WML) $(<F)
ifeq "$(LANGUAGE)" "en"
$(WMLBASE)/../touch_translations.pl $(CURDIR)/$(<F) $(LANGUAGE)
endif
ifneq "$(findstring /international/,$(CURDIR))" ""
$(WMLBASE)/../touch_translations.pl $(CURDIR)/$(<F) $(LANGUAGE)
endif
endif
ifndef NOGENERICINSTDEP
$(HTMLDIR)/%.$(LANGUAGE).html: %.$(LANGUAGE).html
@echo copying $(@F) to $(HTMLDIR)
-@install -m 664 -p $(@F) $(HTMLDIR)
ifeq ($(LANGUAGE),en)
@echo making a link $(@D)/$(*F).html -\> $(@F)
@ln -sf $(@F) $(@D)/$(*F).html
endif
endif
$(IMGDESTFILES): $(IMGFILES)
install -m 664 -p $(@F) $(HTMLDIR)
ifeq "$(LANGUAGE)" "en"
[ -f "$(HTMLDIR)/$(basename $(basename $(@F)))$(suffix $(@F))" ] \
|| ln -s $(@F) $(HTMLDIR)/$(basename $(basename $(@F)))$(suffix $(@F))
endif
# template dependencies
(...)
.SUFFIXES:
.PHONY: all $(existing-SUBS) install $(existing-SUBS-install)
.PHONY: clean $(existing-SUBS-clean) cleandest $(existing-SUBS-cleandest)
La compilación se hará, en general, desde el directorio raíz del servidor que define todos los idiomas (subdirectorios) existentes, como se observa a continuación.
Cada directorio y subdirectorio de éste tiene que tener un fichero Makefile que indique explícitamente la información necesaria para procesarlo. Dado que la mayor parte de la información parte. Se puede observar a continuación el fichero necesarios para la compilación en un subdirectorio. En este caso, se trata de un fichero Makefile utilizado en un directorio de un nivel de profundidad con respecto a la raíz. Como se puede ver sólo es necesario indicar la ruta hacia el fichero raíz, el directorio actual y los subdirectorios de éste.
Cada Makefile incluye al fichero en el raíz Make.lang, mostrado a continuación, que incluye la definición del lenguaje (necesaria para pasarlo como opción a la compilación de ficheros WML) e incluye, directamente, el fichero general mostrado previamente.
Incluir un nuevo directorio para procesarse con esta estructura de ficheros es bien sencillo. Una vez, es necesario crear un fichero Makefile dentro del mismo, la forma más fácil consiste en copiar el fichero Makefile del directorio anterior, para utilizarlo como plantilla. Dentro de éste se modificarán las variables: WMLBASE (que indica dónde está el raíz de los directorios WML, por lo que se añadirá al anterior un ../ ya que hemos profundizado un directorio), CUR_DIR (añadiéndole el directorio actual ya que aquí tendríamos el valor del padre), SUBS (en principio dejándolo en blanco ya que aún no existe ningún subdirectorio) y dejar en blanco el objetivo local:. Para que la estructura sea capaz de entrar recursivamente en el directorio recién creado será necesario añadir el directorio recién creado a la variable SUBS del fichero Makefile del directorio padre.
Una vez realizado estas ediciones (que son incluso susceptibles de realizarse de forma automática) ya se tendrá un nuevo directorio incluido en la estructura del servidor y bastará con ir incluyendo los ficheros .wml (o ficheros en otros formatos que reconozca el Makefile.common) que se deseen. Estos serán procesados adecuadamente ya que las reglas para procesarlos están en el directorio raíz.
Si se desea que en este directorio tenga lugar algún procesamiento específico, se reserva para esto el objetivo local. Este objetivo será procesado antes de cualquier otra cosa en el momento de hacer make en el directorio, con lo que puede aprovecharse para generar documentos de forma automática. En el caso de Debian este objetivo se utiliza para generar automáticamente algunos ficheros realizados en LaTeX o para llevar a cabo algún procesamiento necesario previo a la generación de las páginas HTML.
Las páginas fuente del servidor está dividido en tantos directorios como idiomas traducidos, de esta forma se evita que se mezclen en un sólo directorio el trabajo de múltiples traductores. De esta forma también se facilita su distribución mediante CVS. Para todos los idiomas, se mantiene una serie de ficheros comunes necesarios. Estos ficheros se mantienen en el directorio raíz y contienen, entre otros, los ficheros con las definiciones de compilación, programas para comprobar el nivel de actualización de una traducción determinada, y herramientas de ayuda para generar por primera vez una versión del servidor traducido.
Por debajo del directorio raíz se ubican todos los directorios de cada uno de los idiomas (inglés, francés, griego, español.. hasta un total de veintitrés en el momento de escribir ésto) que tienen, todos, la misma estructura de directorios y los mismos ficheros (cuando están traducidos). El directorio en inglés es el que sirve de referencia para los traductores salvo para algunos documentos que han sido escritos originalmente en otro idioma (como es el caso de las páginas de coordinación de cada una de las traducciones, ubicadas en el directorio "international"). Y es en éste directorio donde se ubican las plantillas generales que contienen las traducciones de las distintas "rodajas" en elementos utilizados con frecuencia en todo el servidor.