Here's a brief overview of how our wml set-up works.
----------------------------------------------------
Here's a typical wml file:
https://svn.torproject.org/svn/website/trunk/en/bridges.wml
The top of the file has:
## translation metadata
# Revision: $Revision$
# Translation-Priority: 1-high
#include "head.wmi" TITLE="Tor: Bridges"
<div class="main-column">
and the bottom of the file has:
</div><!-- #main -->
#include <foot.wmi>
and the middle is standard html, plus a few extra tags like
<page> that we've added to automatically link to the translated
pages when they exist. So that wml page produces this html page:
https://www.torproject.org/bridges aka
https://www.torproject.org/bridges.html.en
Then head.wmi and foot.wmi are just other mostly-html files you import
to handle the repeat parts of each page (well, that plus some embedded
perl scripts to generate some of the static content).
https://svn.torproject.org/svn/website/trunk/include/head.wmi
https://svn.torproject.org/svn/website/trunk/en/foot.wmi
You can basically ignore the wml part of them, and to a first
approximation just think of them as more html.
So in summary, wml is like html with a bit more markup.
----------------------------------------------------
Where it gets interesting is the download page:
https://svn.torproject.org/svn/website/trunk/en/easy-download.wml
It has the standard header and footer section, but in the body of the page
it includes links like <a href="<package-osx-bundle-stable>". Rather than
putting URLs and Tor versions into every wml page, and then requiring
the translators to update their page whenever we bump a version number,
we instead define each URL and version as a new wml element:
https://svn.torproject.org/svn/website/trunk/include/versions.wmi