| 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.